Linux-stable-mirror April 2022

linux-stable-mirror@lists.linaro.org

403 participants
1657 discussions

FAILED: patch "[PATCH] iio: adc: aspeed: Add divider flag to fix incorrect voltage" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 571426631acf46e2999c7ecd1e9d048172969a43 Mon Sep 17 00:00:00 2001 From: Billy Tsai <billy_tsai(a)aspeedtech.com> Date: Mon, 21 Feb 2022 09:27:05 +0800 Subject: [PATCH] iio: adc: aspeed: Add divider flag to fix incorrect voltage reading. The formula for the ADC sampling period in ast2400/ast2500 is: ADC clock period = PCLK * 2 * (ADC0C[31:17] + 1) * (ADC0C[9:0]) When ADC0C[9:0] is set to 0 the sampling voltage will be lower than expected, because the hardware may not have enough time to charge/discharge to a stable voltage. This patch use the flag CLK_DIVIDER_ONE_BASED which will use the raw value read from the register, with the value of zero considered invalid to conform to the corrected formula. Fixes: 573803234e72 ("iio: Aspeed ADC") Reported-by: Konstantin Klubnichkin <kitsok(a)yandex-team.ru> Signed-off-by: Billy Tsai <billy_tsai(a)aspeedtech.com> Reviewed-by: Joel Stanley <joel(a)jms.id.au> Link: https://lore.kernel.org/r/20220221012705.22008-1-billy_tsai@aspeedtech.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/adc/aspeed_adc.c b/drivers/iio/adc/aspeed_adc.c index e939b84cbb56..0793d2474cdc 100644 --- a/drivers/iio/adc/aspeed_adc.c +++ b/drivers/iio/adc/aspeed_adc.c @@ -539,7 +539,9 @@ static int aspeed_adc_probe(struct platform_device *pdev) data->clk_scaler = devm_clk_hw_register_divider( &pdev->dev, clk_name, clk_parent_name, scaler_flags, data->base + ASPEED_REG_CLOCK_CONTROL, 0, - data->model_data->scaler_bit_width, 0, &data->clk_lock); + data->model_data->scaler_bit_width, + data->model_data->need_prescaler ? CLK_DIVIDER_ONE_BASED : 0, + &data->clk_lock); if (IS_ERR(data->clk_scaler)) return PTR_ERR(data->clk_scaler);

3 years

[PATCH] MIPS: crypto: Fix CRC32 code

by Paul Cercueil

Commit 67512a8cf5a7 ("MIPS: Avoid macro redefinitions") changed how the MIPS register macros were defined, in order to allow the code to compile under LLVM/Clang. The MIPS CRC32 code however wasn't updated accordingly, causing a build bug when using a MIPS32r6 toolchain without CRC support. Update the CRC32 code to use the macros correctly, to fix the build failures. Fixes: 67512a8cf5a7 ("MIPS: Avoid macro redefinitions") Cc: <stable(a)vger.kernel.org> Signed-off-by: Paul Cercueil <paul(a)crapouillou.net> Reported-by: kernel test robot <lkp(a)intel.com> --- arch/mips/crypto/crc32-mips.c | 46 ++++++++++++++++++++--------------- 1 file changed, 26 insertions(+), 20 deletions(-) diff --git a/arch/mips/crypto/crc32-mips.c b/arch/mips/crypto/crc32-mips.c index 0a03529cf317..3e4f5ba104f8 100644 --- a/arch/mips/crypto/crc32-mips.c +++ b/arch/mips/crypto/crc32-mips.c @@ -28,7 +28,7 @@ enum crc_type { }; #ifndef TOOLCHAIN_SUPPORTS_CRC -#define _ASM_MACRO_CRC32(OP, SZ, TYPE) \ +#define _ASM_SET_CRC(OP, SZ, TYPE) \ _ASM_MACRO_3R(OP, rt, rs, rt2, \ ".ifnc \\rt, \\rt2\n\t" \ ".error \"invalid operands \\\"" #OP " \\rt,\\rs,\\rt2\\\"\"\n\t" \ @@ -37,30 +37,36 @@ _ASM_MACRO_3R(OP, rt, rs, rt2, \ ((SZ) << 6) | ((TYPE) << 8)) \ _ASM_INSN32_IF_MM(0x00000030 | (__rs << 16) | (__rt << 21) | \ ((SZ) << 14) | ((TYPE) << 3))) -_ASM_MACRO_CRC32(crc32b, 0, 0); -_ASM_MACRO_CRC32(crc32h, 1, 0); -_ASM_MACRO_CRC32(crc32w, 2, 0); -_ASM_MACRO_CRC32(crc32d, 3, 0); -_ASM_MACRO_CRC32(crc32cb, 0, 1); -_ASM_MACRO_CRC32(crc32ch, 1, 1); -_ASM_MACRO_CRC32(crc32cw, 2, 1); -_ASM_MACRO_CRC32(crc32cd, 3, 1); -#define _ASM_SET_CRC "" +#define _ASM_UNSET_CRC(op, SZ, TYPE) ".purgem " #op "\n\t" #else /* !TOOLCHAIN_SUPPORTS_CRC */ -#define _ASM_SET_CRC ".set\tcrc\n\t" +#define _ASM_SET_CRC(op, SZ, TYPE) ".set\tcrc\n\t" +#define _ASM_UNSET_CRC(op, SZ, TYPE) #endif -#define _CRC32(crc, value, size, type) \ -do { \ - __asm__ __volatile__( \ - ".set push\n\t" \ - _ASM_SET_CRC \ - #type #size " %0, %1, %0\n\t" \ - ".set pop" \ - : "+r" (crc) \ - : "r" (value)); \ +#define __CRC32(crc, value, op, SZ, TYPE) \ +do { \ + __asm__ __volatile__( \ + ".set push\n\t" \ + _ASM_SET_CRC(op, SZ, TYPE) \ + #op " %0, %1, %0\n\t" \ + _ASM_UNSET_CRC(op, SZ, TYPE) \ + ".set pop" \ + : "+r" (crc) \ + : "r" (value)); \ } while (0) +#define _CRC32_crc32b(crc, value) __CRC32(crc, value, crc32b, 0, 0) +#define _CRC32_crc32h(crc, value) __CRC32(crc, value, crc32h, 1, 0) +#define _CRC32_crc32w(crc, value) __CRC32(crc, value, crc32w, 2, 0) +#define _CRC32_crc32d(crc, value) __CRC32(crc, value, crc32d, 3, 0) +#define _CRC32_crc32cb(crc, value) __CRC32(crc, value, crc32cb, 0, 1) +#define _CRC32_crc32ch(crc, value) __CRC32(crc, value, crc32ch, 1, 1) +#define _CRC32_crc32cw(crc, value) __CRC32(crc, value, crc32cw, 2, 1) +#define _CRC32_crc32cd(crc, value) __CRC32(crc, value, crc32cd, 3, 1) + +#define _CRC32(crc, value, size, op) \ + _CRC32_##op##size(crc, value) + #define CRC32(crc, value, size) \ _CRC32(crc, value, size, crc32) -- 2.35.1

3 years

[PATCH v2] sound/hda: Add NULL check to component match callback function

by Won Chung

Component match callback function needs to check if expected data is passed to it. Without this check, it can cause a NULL pointer dereference when another driver registers a component before i915 drivers have their component master fully bind. Fixes: 7b882fe3e3e8b ("ALSA: hda - handle multiple i915 device instances") Signed-off-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Signed-off-by: Won Chung <wonchung(a)google.com> --- - Add "Fixes" tag - Send to stable(a)vger.kernel.org sound/hda/hdac_i915.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c index efe810af28c5..958b0975fa40 100644 --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -102,13 +102,13 @@ static int i915_component_master_match(struct device *dev, int subcomponent, struct pci_dev *hdac_pci, *i915_pci; struct hdac_bus *bus = data; - if (!dev_is_pci(dev)) + if (!dev_is_pci(dev) || !bus) return 0; hdac_pci = to_pci_dev(bus->dev); i915_pci = to_pci_dev(dev); - if (!strcmp(dev->driver->name, "i915") && + if (dev->driver && !strcmp(dev->driver->name, "i915") && subcomponent == I915_COMPONENT_AUDIO && connectivity_check(i915_pci, hdac_pci)) return 1; -- 2.35.1.1021.g381101b075-goog

3 years

Why rolling trees aren't updated last week?

by Vitaly Chikunov

Hello, Why linux-rolling-lts and linux-rolling-stable trees aren't updated last week and stay on the previous lts and stable releases? Thanks,

3 years

+ mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch added to -mm tree

by Andrew Morton

The patch titled Subject: mm/mempolicy: fix mpol_new leak in shared_policy_replace has been added to the -mm tree. Its filename is mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch This patch should soon appear at https://ozlabs.org/~akpm/mmots/broken-out/mm-mempolicy-fix-mpol_new-leak-in… and later at https://ozlabs.org/~akpm/mmotm/broken-out/mm-mempolicy-fix-mpol_new-leak-in… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Miaohe Lin <linmiaohe(a)huawei.com> Subject: mm/mempolicy: fix mpol_new leak in shared_policy_replace If mpol_new is allocated but not used in restart loop, mpol_new will be freed via mpol_put before returning to the caller. But refcnt is not initialized yet, so mpol_put could not do the right things and might leak the unused mpol_new. This would happen if mempolicy was updated on the shared shmem file while the sp->lock has been dropped during the memory allocation. This issue could be triggered easily with the below code snippet if there are many processes doing the below work at the same time: shmid = shmget((key_t)5566, 1024 * PAGE_SIZE, 0666|IPC_CREAT); shm = shmat(shmid, 0, 0); loop many times { mbind(shm, 1024 * PAGE_SIZE, MPOL_LOCAL, mask, maxnode, 0); mbind(shm + 128 * PAGE_SIZE, 128 * PAGE_SIZE, MPOL_DEFAULT, mask, maxnode, 0); } Link: https://lkml.kernel.org/r/20220329111416.27954-1-linmiaohe@huawei.com Fixes: 42288fe366c4 ("mm: mempolicy: Convert shared_policy mutex to spinlock") Signed-off-by: Miaohe Lin <linmiaohe(a)huawei.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: KOSAKI Motohiro <kosaki.motohiro(a)jp.fujitsu.com> Cc: Mel Gorman <mgorman(a)suse.de> Cc: <stable(a)vger.kernel.org> [3.8 Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/mempolicy.c | 1 + 1 file changed, 1 insertion(+) --- a/mm/mempolicy.c~mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace +++ a/mm/mempolicy.c @@ -2733,6 +2733,7 @@ alloc_new: mpol_new = kmem_cache_alloc(policy_cache, GFP_KERNEL); if (!mpol_new) goto err_out; + atomic_set(&mpol_new->refcnt, 1); goto restart; } _ Patches currently in -mm which might be from linmiaohe(a)huawei.com are mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch mm-shmem-make-shmem_init-return-void.patch mm-memcg-remove-unneeded-nr_scanned.patch mm-mremap-use-helper-mlock_future_check.patch mm-z3fold-declare-z3fold_mount-with-__init.patch mm-z3fold-remove-obsolete-comment-in-z3fold_alloc.patch mm-z3fold-minor-clean-up-for-z3fold_free.patch mm-z3fold-remove-unneeded-page_mapcount_reset-and-clearpageprivate.patch mm-z3fold-remove-confusing-local-variable-l-reassignment.patch mm-z3fold-move-decrement-of-pool-pages_nr-into-__release_z3fold_page.patch mm-z3fold-remove-redundant-list_del_init-of-zhdr-buddy-in-z3fold_free.patch mm-z3fold-remove-unneeded-page_headless-check-in-free_handle.patch mm-compaction-use-helper-isolation_suitable.patch mm-migration-remove-unneeded-local-variable-mapping_locked.patch mm-migration-remove-unneeded-out-label.patch mm-migration-remove-unneeded-local-variable-page_lru.patch mm-migration-fix-the-confusing-pagetranshuge-check.patch mm-migration-use-helper-function-vma_lookup-in-add_page_for_migration.patch mm-migration-use-helper-macro-min-in-do_pages_stat.patch mm-migration-avoid-unneeded-nodemask_t-initialization.patch mm-migration-remove-some-duplicated-codes-in-migrate_pages.patch mm-migration-fix-potential-page-refcounts-leak-in-migrate_pages.patch mm-migration-fix-potential-invalid-node-access-for-reclaim-based-migration.patch mm-migration-fix-possible-do_pages_stat_array-racing-with-memory-offline.patch

3 years

[PATCH v3] iommu/vt-d: calculate mask for non-aligned flushes

by David Stevens

From: David Stevens <stevensd(a)chromium.org> Calculate the appropriate mask for non-size-aligned page selective invalidation. Since psi uses the mask value to mask out the lower order bits of the target address, properly flushing the iotlb requires using a mask value such that [pfn, pfn+pages) all lie within the flushed size-aligned region. This is not normally an issue because iova.c always allocates iovas that are aligned to their size. However, iovas which come from other sources (e.g. userspace via VFIO) may not be aligned. To properly flush the IOTLB, both the start and end pfns need to be equal after applying the mask. That means that the most efficient mask to use is the index of the lowest bit that is equal where all higher bits are also equal. For example, if pfn=0x17f and pages=3, then end_pfn=0x181, so the smallest mask we can use is 8. Any differences above the highest bit of pages are due to carrying, so by xnor'ing pfn and end_pfn and then masking out the lower order bits based on pages, we get 0xffffff00, where the first set bit is the mask we want to use. Fixes: 6fe1010d6d9c ("vfio/type1: DMA unmap chunking") Cc: stable(a)vger.kernel.org Signed-off-by: David Stevens <stevensd(a)chromium.org> Reviewed-by: Kevin Tian <kevin.tian(a)intel.com> --- The seeds of the bug were introduced by f76aec76ec7f6, which simultaniously added the alignement requirement to the iommu driver and made the iova allocator return aligned iovas. However, I don't think there was any way to trigger the bug at that time. The tagged VFIO change is one that actually introduced a code path that could trigger the bug. There may also be other ways to trigger the bug that I am not aware of. v1 -> v2: - Calculate an appropriate mask for non-size-aligned iovas instead of falling back to domain selective flush. v2 -> v3: - Add more detail to commit message. drivers/iommu/intel/iommu.c | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 5b196cfe9ed2..ab2273300346 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -1717,7 +1717,8 @@ static void iommu_flush_iotlb_psi(struct intel_iommu *iommu, unsigned long pfn, unsigned int pages, int ih, int map) { - unsigned int mask = ilog2(__roundup_pow_of_two(pages)); + unsigned int aligned_pages = __roundup_pow_of_two(pages); + unsigned int mask = ilog2(aligned_pages); uint64_t addr = (uint64_t)pfn << VTD_PAGE_SHIFT; u16 did = domain->iommu_did[iommu->seq_id]; @@ -1729,10 +1730,30 @@ static void iommu_flush_iotlb_psi(struct intel_iommu *iommu, if (domain_use_first_level(domain)) { domain_flush_piotlb(iommu, domain, addr, pages, ih); } else { + unsigned long bitmask = aligned_pages - 1; + + /* + * PSI masks the low order bits of the base address. If the + * address isn't aligned to the mask, then compute a mask value + * needed to ensure the target range is flushed. + */ + if (unlikely(bitmask & pfn)) { + unsigned long end_pfn = pfn + pages - 1, shared_bits; + + /* + * Since end_pfn <= pfn + bitmask, the only way bits + * higher than bitmask can differ in pfn and end_pfn is + * by carrying. This means after masking out bitmask, + * high bits starting with the first set bit in + * shared_bits are all equal in both pfn and end_pfn. + */ + shared_bits = ~(pfn ^ end_pfn) & ~bitmask; + mask = shared_bits ? __ffs(shared_bits) : BITS_PER_LONG; + } + /* * Fallback to domain selective flush if no PSI support or - * the size is too big. PSI requires page size to be 2 ^ x, - * and the base address is naturally aligned to the size. + * the size is too big. */ if (!cap_pgsel_inv(iommu->cap) || mask > cap_max_amask_val(iommu->cap)) -- 2.35.1.1094.g7c7d902a7c-goog

3 years

[PATCH] gcc-plugins: latent_entropy: use /dev/urandom

by Jason A. Donenfeld

While the latent entropy plugin mostly doesn't derive entropy from get_random_const() for measuring the call graph, when __latent_entropy is applied to a constant, then it's initialized statically to output from get_random_const(). In that case, this data is derived from a 64-bit seed, which means a buffer of 512 bits doesn't really have that amount of compile-time entropy. This patch fixes that shortcoming by just buffering chunks of /dev/urandom output and doling it out as requested. Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin") Cc: stable(a)vger.kernel.org Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> --- I'm not super familiar with this plugin or its conventions, so pointers would be most welcome if something here looks amiss. The decision to buffer 2k at a time is pretty arbitrary too; I haven't measured usage. scripts/gcc-plugins/latent_entropy_plugin.c | 34 +++++++++------------ 1 file changed, 15 insertions(+), 19 deletions(-) diff --git a/scripts/gcc-plugins/latent_entropy_plugin.c b/scripts/gcc-plugins/latent_entropy_plugin.c index 589454bce930..f238ba6726b8 100644 --- a/scripts/gcc-plugins/latent_entropy_plugin.c +++ b/scripts/gcc-plugins/latent_entropy_plugin.c @@ -82,29 +82,27 @@ __visible int plugin_is_GPL_compatible; static GTY(()) tree latent_entropy_decl; static struct plugin_info latent_entropy_plugin_info = { - .version = "201606141920vanilla", + .version = "202203311920vanilla", .help = "disable\tturn off latent entropy instrumentation\n", }; -static unsigned HOST_WIDE_INT seed; -/* - * get_random_seed() (this is a GCC function) generates the seed. - * This is a simple random generator without any cryptographic security because - * the entropy doesn't come from here. - */ +static unsigned HOST_WIDE_INT rnd_buf[256]; +static size_t rnd_idx = ARRAY_SIZE(rnd_buf); +static int urandom_fd = -1; + static unsigned HOST_WIDE_INT get_random_const(void) { - unsigned int i; - unsigned HOST_WIDE_INT ret = 0; - - for (i = 0; i < 8 * sizeof(ret); i++) { - ret = (ret << 1) | (seed & 1); - seed >>= 1; - if (ret & 1) - seed ^= 0xD800000000000000ULL; + if (urandom_fd < 0) { + urandom_fd = open("/dev/urandom", O_RDONLY); + if (urandom_fd < 0) + abort(); } - - return ret; + if (rnd_idx >= ARRAY_SIZE(rnd_buf)) { + if (read(urandom_fd, rnd_buf, sizeof(rnd_buf)) != sizeof(rnd_buf)) + abort(); + rnd_idx = 0; + } + return rnd_buf[rnd_idx++]; } static tree tree_get_random_const(tree type) @@ -537,8 +535,6 @@ static void latent_entropy_start_unit(void *gcc_data __unused, tree type, id; int quals; - seed = get_random_seed(false); - if (in_lto_p) return; -- 2.35.1

3 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2022