- Linux-stable-mirror - lists.linaro.org

[PATCH 1/2] can: hi311x: Acquire SPI lock on ->do_get_berr_counter

by Marc Kleine-Budde

From: Lukas Wunner <lukas(a)wunner.de> hi3110_get_berr_counter() may run concurrently to the rest of the driver but neglects to acquire the lock protecting access to the SPI device. As a result, it and the rest of the driver may clobber each other's tx and rx buffers. We became aware of this issue because transmission of packets with "cangen -g 0 -i -x" frequently hung. It turns out that agetty executes ->do_get_berr_counter every few seconds via the following call stack: CPU: 2 PID: 1605 Comm: agetty [<7f3f7500>] (hi3110_get_berr_counter [hi311x]) [<7f130204>] (can_fill_info [can_dev]) [<80693bc0>] (rtnl_fill_ifinfo) [<806949ec>] (rtnl_dump_ifinfo) [<806b4834>] (netlink_dump) [<806b4bc8>] (netlink_recvmsg) [<8065f180>] (sock_recvmsg) [<80660f90>] (___sys_recvmsg) [<80661e7c>] (__sys_recvmsg) [<80661ec0>] (SyS_recvmsg) [<80108b20>] (ret_fast_syscall+0x0/0x1c) agetty listens to netlink messages in order to update the login prompt when IP addresses change (if /etc/issue contains \4 or \6 escape codes): https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/commit/?id=e… It's a useful feature, though it seems questionable that it causes CAN bit error statistics to be queried. Be that as it may, if hi3110_get_berr_counter() is invoked while a frame is sent by hi3110_hw_tx(), bogus SPI transfers like the following may occur: => 12 00 (hi3110_get_berr_counter() wanted to transmit EC 00 to query the transmit error counter, but the first byte was overwritten by hi3110_hw_tx_frame()) => EA 00 3E 80 01 FB (hi3110_hw_tx_frame() wanted to transmit a frame, but the first byte was overwritten by hi3110_get_berr_counter() because it wanted to query the receive error counter) This sequence hangs the transmission because the driver believes it has sent a frame and waits for the interrupt signaling completion, but in reality the chip has never sent away the frame since the commands it received were malformed. Fix by acquiring the SPI lock in hi3110_get_berr_counter(). I've scrutinized the entire driver for further unlocked SPI accesses but found no others. Cc: Mathias Duckeck <m.duckeck(a)kunbus.de> Cc: Akshay Bhat <akshay.bhat(a)timesys.com> Cc: Casey Fitzpatrick <casey.fitzpatrick(a)timesys.com> Cc: Stef Walter <stefw(a)redhat.com> Cc: Karel Zak <kzak(a)redhat.com> Cc: stable(a)vger.kernel.org # v4.12+ Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Reviewed-by: Akshay Bhat <akshay.bhat(a)timesys.com> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- drivers/net/can/spi/hi311x.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/can/spi/hi311x.c b/drivers/net/can/spi/hi311x.c index 5590c559a8ca..c2cf254e4e95 100644 --- a/drivers/net/can/spi/hi311x.c +++ b/drivers/net/can/spi/hi311x.c @@ -427,8 +427,10 @@ static int hi3110_get_berr_counter(const struct net_device *net, struct hi3110_priv *priv = netdev_priv(net); struct spi_device *spi = priv->spi; + mutex_lock(&priv->hi3110_lock); bec->txerr = hi3110_read(spi, HI3110_READ_TEC); bec->rxerr = hi3110_read(spi, HI3110_READ_REC); + mutex_unlock(&priv->hi3110_lock); return 0; } -- 2.17.0

7 years, 7 months

1
0
0 0

[PATCH] mtd: rawnand: micron: Fix support for on-die ECC

by Boris Brezillon

It looks like the NAND_STATUS_FAIL bit is sticky after an ECC failure, which leads all READ operations following the failing one to report an ECC failure. Reset the chip to clear the NAND_STATUS_FAIL bit. Note that this behavior is not document in the datasheet, but resetting the chip is the only solution we found to fix the problem. Fixes: 9748e1d87573 ("mtd: nand: add support for Micron on-die ECC") Cc: <stable(a)vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com> Cc: Thomas Petazzoni <thomas.petazzoni(a)bootlin.com> Cc: Bean Huo <beanhuo(a)micron.com> Cc: Peter Pan <peterpandong(a)micron.com> --- Peter, Bean, Can you confirm this behavior, or ask someone in Micron who can confirm it? Also, if a RESET is actually needed, it would be good to update the datasheet accordingly. And if that's not the case, can you explain why the NAND_STATUS_FAIL bit is stuck and how to clear it (I tried a 0x00 command, A.K.A. READ STATUS EXIT, but it does not clear this bit, ERASE and PROGRAM seem to clear the bit, but that's clearly not the kind of operation I can do when the user asks for a READ)? Thanks, Boris --- drivers/mtd/nand/raw/nand_micron.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/drivers/mtd/nand/raw/nand_micron.c b/drivers/mtd/nand/raw/nand_micron.c index 0af45b134c0c..a915f568f6a3 100644 --- a/drivers/mtd/nand/raw/nand_micron.c +++ b/drivers/mtd/nand/raw/nand_micron.c @@ -153,6 +153,23 @@ micron_nand_read_page_on_die_ecc(struct mtd_info *mtd, struct nand_chip *chip, ret = nand_read_data_op(chip, chip->oob_poi, mtd->oobsize, false); + /* + * Looks like the NAND_STATUS_FAIL bit is sticky after an ECC failure, + * which leads all READ operations following the failing one to report + * an ECC failure. + * Reset the chip to clear it. + * + * Note that this behavior is not document in the datasheet, but + * resetting the chip is the only solution we found to clear this bit. + */ + if (status & NAND_STATUS_FAIL) { + int cs = page >> (chip->chip_shift - chip->page_shift); + + chip->select_chip(mtd, -1); + nand_reset(chip, cs); + chip->select_chip(mtd, cs); + } + out: micron_nand_on_die_ecc_setup(chip, false); -- 2.14.1

7 years, 7 months

2
3
0 0

[PATCH] swiotlb: fix inversed DMA_ATTR_NO_WARN test

by Prasanthi Chellakumar

From: Michel Dänzer <michel.daenzer(a)amd.com> The result was printing the warning only when we were explicitly asked not to. Cc: stable(a)vger.kernel.org Fixes: 0176adb004065d6815a8e67946752df4cd947c5b "swiotlb: refactor coherent buffer allocation" Signed-off-by: Michel Dänzer <michel.daenzer(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com>. Signed-off-by: Christoph Hellwig <hch(a)lst.de> --- lib/swiotlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/swiotlb.c b/lib/swiotlb.c index fece575..12fbaa4 100644 --- a/lib/swiotlb.c +++ b/lib/swiotlb.c @@ -737,7 +737,7 @@ swiotlb_alloc_buffer(struct device *dev, size_t size, dma_addr_t *dma_handle, swiotlb_tbl_unmap_single(dev, phys_addr, size, DMA_TO_DEVICE, DMA_ATTR_SKIP_CPU_SYNC); out_warn: - if ((attrs & DMA_ATTR_NO_WARN) && printk_ratelimit()) { + if (!(attrs & DMA_ATTR_NO_WARN) && printk_ratelimit()) { dev_warn(dev, "swiotlb: coherent allocation failed, size=%zu\n", size); -- 2.7.4

7 years, 7 months

1
0
0 0

+ lib-test_bitmapc-fix-bitmap-optimisation-tests-to-report-errors-correctly.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: lib/test_bitmap.c: fix bitmap optimisation tests to report errors correctly has been added to the -mm tree. Its filename is lib-test_bitmapc-fix-bitmap-optimisation-tests-to-report-errors-correctly.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/lib-test_bitmapc-fix-bitmap-optimi… and later at http://ozlabs.org/~akpm/mmotm/broken-out/lib-test_bitmapc-fix-bitmap-optimi… 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: Matthew Wilcox <mawilcox(a)microsoft.com> Subject: lib/test_bitmap.c: fix bitmap optimisation tests to report errors correctly I had neglected to increment the error counter when the tests failed, which made the tests noisy when they fail, but not actually return an error code. Link: http://lkml.kernel.org/r/20180509114328.9887-1-mpe@ellerman.id.au Fixes: 3cc78125a081 ("lib/test_bitmap.c: add optimisation tests") Signed-off-by: Matthew Wilcox <mawilcox(a)microsoft.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Reported-by: Michael Ellerman <mpe(a)ellerman.id.au> Tested-by: Michael Ellerman <mpe(a)ellerman.id.au> Reviewed-by: Kees Cook <keescook(a)chromium.org> Cc: Yury Norov <ynorov(a)caviumnetworks.com> Cc: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Cc: Geert Uytterhoeven <geert(a)linux-m68k.org> Cc: <stable(a)vger.kernel.org> [4.13+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/test_bitmap.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) diff -puN lib/test_bitmap.c~lib-test_bitmapc-fix-bitmap-optimisation-tests-to-report-errors-correctly lib/test_bitmap.c --- a/lib/test_bitmap.c~lib-test_bitmapc-fix-bitmap-optimisation-tests-to-report-errors-correctly +++ a/lib/test_bitmap.c @@ -331,23 +331,32 @@ static void noinline __init test_mem_opt unsigned int start, nbits; for (start = 0; start < 1024; start += 8) { - memset(bmap1, 0x5a, sizeof(bmap1)); - memset(bmap2, 0x5a, sizeof(bmap2)); for (nbits = 0; nbits < 1024 - start; nbits += 8) { + memset(bmap1, 0x5a, sizeof(bmap1)); + memset(bmap2, 0x5a, sizeof(bmap2)); + bitmap_set(bmap1, start, nbits); __bitmap_set(bmap2, start, nbits); - if (!bitmap_equal(bmap1, bmap2, 1024)) + if (!bitmap_equal(bmap1, bmap2, 1024)) { printk("set not equal %d %d\n", start, nbits); - if (!__bitmap_equal(bmap1, bmap2, 1024)) + failed_tests++; + } + if (!__bitmap_equal(bmap1, bmap2, 1024)) { printk("set not __equal %d %d\n", start, nbits); + failed_tests++; + } bitmap_clear(bmap1, start, nbits); __bitmap_clear(bmap2, start, nbits); - if (!bitmap_equal(bmap1, bmap2, 1024)) + if (!bitmap_equal(bmap1, bmap2, 1024)) { printk("clear not equal %d %d\n", start, nbits); - if (!__bitmap_equal(bmap1, bmap2, 1024)) + failed_tests++; + } + if (!__bitmap_equal(bmap1, bmap2, 1024)) { printk("clear not __equal %d %d\n", start, nbits); + failed_tests++; + } } } } _ Patches currently in -mm which might be from mawilcox(a)microsoft.com are lib-test_bitmapc-fix-bitmap-optimisation-tests-to-report-errors-correctly.patch slab-__gfp_zero-is-incompatible-with-a-constructor.patch ida-remove-simple_ida_lock.patch

7 years, 7 months

1
0
0 0

[PATCH 13/13] x86/pkeys: Do not special case protection key 0

by Dave Hansen

From: Dave Hansen <dave.hansen(a)linux.intel.com> mm_pkey_is_allocated() treats pkey 0 as unallocated. That is inconsistent with the manpages, and also inconsistent with mm->context.pkey_allocation_map. Stop special casing it and only disallow values that are actually bad (< 0). The end-user visible effect of this is that you can now use mprotect_pkey() to set pkey=0. This is a bit nicer than what Ram proposed[1] because it is simpler and removes special-casing for pkey 0. On the other hand, it does allow applications to pkey_free() pkey-0, but that's just a silly thing to do, so we are not going to protect against it. The scenario that could happen is similar to what happens if you free any other pkey that is in use: it might get reallocated later and used to protect some other data. The most likely scenario is that pkey-0 comes back from pkey_alloc(), an access-disable or write-disable bit is set in PKRU for it, and the next stack access will SIGSEGV. It's not horribly different from if you mprotect()'d your stack or heap to be unreadable or unwritable, which is generally very foolish, but also not explicitly prevented by the kernel. 1. http://lkml.kernel.org/r/1522112702-27853-1-git-send-email-linuxram@us.ibm.… Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Fixes: 58ab9a088dda ("x86/pkeys: Check against max pkey to avoid overflows") Cc: stable(a)vger.kernel.org Cc: Ram Pai <linuxram(a)us.ibm.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Dave Hansen <dave.hansen(a)intel.com> Cc: Michael Ellermen <mpe(a)ellerman.id.au> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Andrew Morton <akpm(a)linux-foundation.org>p Cc: Shuah Khan <shuah(a)kernel.org> --- b/arch/x86/include/asm/mmu_context.h | 2 +- b/arch/x86/include/asm/pkeys.h | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff -puN arch/x86/include/asm/mmu_context.h~x86-pkey-0-default-allocated arch/x86/include/asm/mmu_context.h --- a/arch/x86/include/asm/mmu_context.h~x86-pkey-0-default-allocated 2018-05-09 09:20:24.362698393 -0700 +++ b/arch/x86/include/asm/mmu_context.h 2018-05-09 09:20:24.367698393 -0700 @@ -193,7 +193,7 @@ static inline int init_new_context(struc #ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS if (cpu_feature_enabled(X86_FEATURE_OSPKE)) { - /* pkey 0 is the default and always allocated */ + /* pkey 0 is the default and allocated implicitly */ mm->context.pkey_allocation_map = 0x1; /* -1 means unallocated or invalid */ mm->context.execute_only_pkey = -1; diff -puN arch/x86/include/asm/pkeys.h~x86-pkey-0-default-allocated arch/x86/include/asm/pkeys.h --- a/arch/x86/include/asm/pkeys.h~x86-pkey-0-default-allocated 2018-05-09 09:20:24.364698393 -0700 +++ b/arch/x86/include/asm/pkeys.h 2018-05-09 09:20:24.367698393 -0700 @@ -51,10 +51,10 @@ bool mm_pkey_is_allocated(struct mm_stru { /* * "Allocated" pkeys are those that have been returned - * from pkey_alloc(). pkey 0 is special, and never - * returned from pkey_alloc(). + * from pkey_alloc() or pkey 0 which is allocated + * implicitly when the mm is created. */ - if (pkey <= 0) + if (pkey < 0) return false; if (pkey >= arch_max_pkey()) return false; _

7 years, 7 months

1
0
0 0

[PATCH 09/13] x86/pkeys: Override pkey when moving away from PROT_EXEC

by Dave Hansen

From: Dave Hansen <dave.hansen(a)linux.intel.com> I got a bug report that the following code (roughly) was causing a SIGSEGV: mprotect(ptr, size, PROT_EXEC); mprotect(ptr, size, PROT_NONE); mprotect(ptr, size, PROT_READ); *ptr = 100; The problem is hit when the mprotect(PROT_EXEC) is implicitly assigned a protection key to the VMA, and made that key ACCESS_DENY|WRITE_DENY. The PROT_NONE mprotect() failed to remove the protection key, and the PROT_NONE-> PROT_READ left the PTE usable, but the pkey still in place and left the memory inaccessible. To fix this, we ensure that we always "override" the pkee at mprotect() if the VMA does not have execute-only permissions, but the VMA has the execute-only pkey. We had a check for PROT_READ/WRITE, but it did not work for PROT_NONE. This entirely removes the PROT_* checks, which ensures that PROT_NONE now works. Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Fixes: 62b5f7d013f ("mm/core, x86/mm/pkeys: Add execute-only protection keys support") Reported-by: Shakeel Butt <shakeelb(a)google.com> Cc: stable(a)vger.kernel.org Cc: Ram Pai <linuxram(a)us.ibm.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Dave Hansen <dave.hansen(a)intel.com> Cc: Michael Ellermen <mpe(a)ellerman.id.au> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Shuah Khan <shuah(a)kernel.org> --- b/arch/x86/include/asm/pkeys.h | 12 +++++++++++- b/arch/x86/mm/pkeys.c | 21 +++++++++++---------- 2 files changed, 22 insertions(+), 11 deletions(-) diff -puN arch/x86/include/asm/pkeys.h~pkeys-abandon-exec-only-pkey-more-aggressively arch/x86/include/asm/pkeys.h --- a/arch/x86/include/asm/pkeys.h~pkeys-abandon-exec-only-pkey-more-aggressively 2018-05-09 09:20:22.295698398 -0700 +++ b/arch/x86/include/asm/pkeys.h 2018-05-09 09:20:22.300698398 -0700 @@ -2,6 +2,8 @@ #ifndef _ASM_X86_PKEYS_H #define _ASM_X86_PKEYS_H +#define ARCH_DEFAULT_PKEY 0 + #define arch_max_pkey() (boot_cpu_has(X86_FEATURE_OSPKE) ? 16 : 1) extern int arch_set_user_pkey_access(struct task_struct *tsk, int pkey, @@ -15,7 +17,7 @@ extern int __execute_only_pkey(struct mm static inline int execute_only_pkey(struct mm_struct *mm) { if (!boot_cpu_has(X86_FEATURE_OSPKE)) - return 0; + return ARCH_DEFAULT_PKEY; return __execute_only_pkey(mm); } @@ -56,6 +58,14 @@ bool mm_pkey_is_allocated(struct mm_stru return false; if (pkey >= arch_max_pkey()) return false; + /* + * The exec-only pkey is set in the allocation map, but + * is not available to any of the user interfaces like + * mprotect_pkey(). + */ + if (pkey == mm->context.execute_only_pkey) + return false; + return mm_pkey_allocation_map(mm) & (1U << pkey); } diff -puN arch/x86/mm/pkeys.c~pkeys-abandon-exec-only-pkey-more-aggressively arch/x86/mm/pkeys.c --- a/arch/x86/mm/pkeys.c~pkeys-abandon-exec-only-pkey-more-aggressively 2018-05-09 09:20:22.297698398 -0700 +++ b/arch/x86/mm/pkeys.c 2018-05-09 09:20:22.301698398 -0700 @@ -94,26 +94,27 @@ int __arch_override_mprotect_pkey(struct */ if (pkey != -1) return pkey; - /* - * Look for a protection-key-drive execute-only mapping - * which is now being given permissions that are not - * execute-only. Move it back to the default pkey. - */ - if (vma_is_pkey_exec_only(vma) && - (prot & (PROT_READ|PROT_WRITE))) { - return 0; - } + /* * The mapping is execute-only. Go try to get the * execute-only protection key. If we fail to do that, * fall through as if we do not have execute-only - * support. + * support in this mm. */ if (prot == PROT_EXEC) { pkey = execute_only_pkey(vma->vm_mm); if (pkey > 0) return pkey; + } else if (vma_is_pkey_exec_only(vma)) { + /* + * Protections are *not* PROT_EXEC, but the mapping + * is using the exec-only pkey. This mapping was + * PROT_EXEC and will no longer be. Move back to + * the default pkey. + */ + return ARCH_DEFAULT_PKEY; } + /* * This is a vanilla, non-pkey mprotect (or we failed to * setup execute-only), inherit the pkey from the VMA we _

7 years, 7 months

1
0
0 0

v4.9.99 build: 0 failures 2 warnings (v4.9.99)

by Build bot for Mark Brown

Tree/Branch: v4.9.99 Git describe: v4.9.99 Commit: 04cd74a759 Linux 4.9.99 Build Time: 83 min 17 sec Passed: 11 / 11 (100.00 %) Failed: 0 / 11 ( 0.00 %) Errors: 0 Warnings: 2 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 1 warnings 0 mismatches : arm64-allmodconfig 1 warnings 0 mismatches : x86_64-allmodconfig ------------------------------------------------------------------------------- Warnings Summary: 2 1 drivers/target/iscsi/iscsi_target.o: warning: objtool: iscsit_handle_task_mgt_cmd()+0x78b: sibling call from callable instruction with changed frame pointer 1 ../include/linux/sched.h:2349:56: warning: 'noio_flag' may be used uninitialized in this function [-Wmaybe-uninitialized] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- arm64-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../include/linux/sched.h:2349:56: warning: 'noio_flag' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- x86_64-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: drivers/target/iscsi/iscsi_target.o: warning: objtool: iscsit_handle_task_mgt_cmd()+0x78b: sibling call from callable instruction with changed frame pointer ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

7 years, 7 months

1
0
0 0

[PATCH 3/3] x86/mm: disable ioremap free page handling on x86-PAE

by Toshi Kani

ioremap() supports pmd mappings on x86-PAE. However, kernel's pmd tables are not shared among processes on x86-PAE. Therefore, any update to sync'd pmd entries need re-syncing. Freeing a pte page also leads to a vmalloc fault and hits the BUG_ON in vmalloc_sync_one(). Disable free page handling on x86-PAE. pud_free_pmd_page() and pmd_free_pte_page() simply return 0 if a given pud/pmd entry is present. This assures that ioremap() does not update sync'd pmd entries at the cost of falling back to pte mappings. Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces") Reported-by: Joerg Roedel <joro(a)8bytes.org> Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: "H. Peter Anvin" <hpa(a)zytor.com> Cc: Joerg Roedel <joro(a)8bytes.org> Cc: <stable(a)vger.kernel.org> --- arch/x86/mm/pgtable.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c index 816fd41ee854..809115150d8b 100644 --- a/arch/x86/mm/pgtable.c +++ b/arch/x86/mm/pgtable.c @@ -715,6 +715,7 @@ int pmd_clear_huge(pmd_t *pmd) return 0; } +#ifdef CONFIG_X86_64 /** * pud_free_pmd_page - Clear pud entry and free pmd page. * @pud: Pointer to a PUD. @@ -784,4 +785,22 @@ int pmd_free_pte_page(pmd_t *pmd, unsigned long addr) return 1; } + +#else /* !CONFIG_X86_64 */ + +int pud_free_pmd_page(pud_t *pud, unsigned long addr) +{ + return pud_none(*pud); +} + +/* + * Disable free page handling on x86-PAE. This assures that ioremap() + * does not update sync'd pmd entries. See vmalloc_sync_one(). + */ +int pmd_free_pte_page(pmd_t *pmd, unsigned long addr) +{ + return pmd_none(*pmd); +} + +#endif /* CONFIG_X86_64 */ #endif /* CONFIG_HAVE_ARCH_HUGE_VMAP */

7 years, 7 months

2
1
0 0

patch "iio: adc: select buffer for at91-sama5d2_adc" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: select buffer for at91-sama5d2_adc to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 76974ef9d1bf397b7bb97892a3b3bc516a1fc2c2 Mon Sep 17 00:00:00 2001 From: Eugen Hristev <eugen.hristev(a)microchip.com> Date: Mon, 16 Apr 2018 09:54:03 +0300 Subject: iio: adc: select buffer for at91-sama5d2_adc We need to select the buffer code, otherwise we get build errors with undefined functions on the trigger and buffer, if we select just IIO and then AT91_SAMA5D2_ADC from menuconfig This adds a Kconfig 'select' statement like other ADC drivers have it already. Fixes: 5e1a1da0f8c9 ("iio: adc: at91-sama5d2_adc: add hw trigger and buffer support") Signed-off-by: Eugen Hristev <eugen.hristev(a)microchip.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index 72bc2b71765a..47bbed3afc8f 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -159,6 +159,7 @@ config AT91_SAMA5D2_ADC depends on ARCH_AT91 || COMPILE_TEST depends on HAS_IOMEM depends on HAS_DMA + select IIO_BUFFER select IIO_TRIGGERED_BUFFER help Say yes here to build support for Atmel SAMA5D2 ADC which is -- 2.17.0

7 years, 7 months

1
0
0 0

patch "iio: hid-sensor-trigger: Fix sometimes not powering up the sensor" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: hid-sensor-trigger: Fix sometimes not powering up the sensor to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 6f92253024d9d947a4f454654840ce479e251376 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede(a)redhat.com> Date: Sat, 14 Apr 2018 17:09:09 +0200 Subject: iio: hid-sensor-trigger: Fix sometimes not powering up the sensor after resume hid_sensor_set_power_work() powers the sensors back up after a resume based on the user_requested_state atomic_t. But hid_sensor_power_state() treats this as a boolean flag, leading to the following problematic scenario: 1) Some app starts using the iio-sensor in buffered / triggered mode, hid_sensor_data_rdy_trigger_set_state(true) gets called, setting user_requested_state to 1. 2) Something directly accesses a _raw value through sysfs, leading to a call to hid_sensor_power_state(true) followed by hid_sensor_power_state(false) call, this sets user_requested_state to 1 followed by setting it to 0. 3) Suspend/resume the machine, hid_sensor_set_power_work() now does NOT power the sensor back up because user_requested_state (wrongly) is 0. Which stops the app using the sensor in buffered mode from receiving any new values. This commit changes user_requested_state to a counter tracking how many times hid_sensor_power_state(true) was called instead, fixing this. Cc: Bastien Nocera <hadess(a)hadess.net> Cc: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/common/hid-sensors/hid-sensor-trigger.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c index cfb6588565ba..4905a997a7ec 100644 --- a/drivers/iio/common/hid-sensors/hid-sensor-trigger.c +++ b/drivers/iio/common/hid-sensors/hid-sensor-trigger.c @@ -178,14 +178,14 @@ int hid_sensor_power_state(struct hid_sensor_common *st, bool state) #ifdef CONFIG_PM int ret; - atomic_set(&st->user_requested_state, state); - if (atomic_add_unless(&st->runtime_pm_enable, 1, 1)) pm_runtime_enable(&st->pdev->dev); - if (state) + if (state) { + atomic_inc(&st->user_requested_state); ret = pm_runtime_get_sync(&st->pdev->dev); - else { + } else { + atomic_dec(&st->user_requested_state); pm_runtime_mark_last_busy(&st->pdev->dev); pm_runtime_use_autosuspend(&st->pdev->dev); ret = pm_runtime_put_autosuspend(&st->pdev->dev); -- 2.17.0

7 years, 7 months

1
0
0 0

patch "iio: adc: at91-sama5d2_adc: fix channel configuration for" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: at91-sama5d2_adc: fix channel configuration for to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From f0c8d1f6dc8eac5a1fbf441c8e080721a7b6c0ff Mon Sep 17 00:00:00 2001 From: Eugen Hristev <eugen.hristev(a)microchip.com> Date: Tue, 10 Apr 2018 11:57:47 +0300 Subject: iio: adc: at91-sama5d2_adc: fix channel configuration for differential channels When iterating through the channels, the index in the array is not the scan index. Added an xlate function to translate to the proper index. The result of the bug is that the channel array is indexed with a wrong index, thus instead of the proper channel, we access invalid memory, which may lead to invalid results and/or corruption. This will be used also for devicetree channel xlate. Fixes: 5e1a1da0f ("iio: adc: at91-sama5d2_adc: add hw trigger and buffer support") Fixes: 073c66201 ("iio: adc: at91-sama5d2_adc: add support for DMA") Signed-off-by: Eugen Hristev <eugen.hristev(a)microchip.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/at91-sama5d2_adc.c | 41 +++++++++++++++++++++++++++--- 1 file changed, 37 insertions(+), 4 deletions(-) diff --git a/drivers/iio/adc/at91-sama5d2_adc.c b/drivers/iio/adc/at91-sama5d2_adc.c index 4eff8351ce29..8729d6524b4d 100644 --- a/drivers/iio/adc/at91-sama5d2_adc.c +++ b/drivers/iio/adc/at91-sama5d2_adc.c @@ -333,6 +333,27 @@ static const struct iio_chan_spec at91_adc_channels[] = { + AT91_SAMA5D2_DIFF_CHAN_CNT + 1), }; +static int at91_adc_chan_xlate(struct iio_dev *indio_dev, int chan) +{ + int i; + + for (i = 0; i < indio_dev->num_channels; i++) { + if (indio_dev->channels[i].scan_index == chan) + return i; + } + return -EINVAL; +} + +static inline struct iio_chan_spec const * +at91_adc_chan_get(struct iio_dev *indio_dev, int chan) +{ + int index = at91_adc_chan_xlate(indio_dev, chan); + + if (index < 0) + return NULL; + return indio_dev->channels + index; +} + static int at91_adc_configure_trigger(struct iio_trigger *trig, bool state) { struct iio_dev *indio = iio_trigger_get_drvdata(trig); @@ -350,8 +371,10 @@ static int at91_adc_configure_trigger(struct iio_trigger *trig, bool state) at91_adc_writel(st, AT91_SAMA5D2_TRGR, status); for_each_set_bit(bit, indio->active_scan_mask, indio->num_channels) { - struct iio_chan_spec const *chan = indio->channels + bit; + struct iio_chan_spec const *chan = at91_adc_chan_get(indio, bit); + if (!chan) + continue; if (state) { at91_adc_writel(st, AT91_SAMA5D2_CHER, BIT(chan->channel)); @@ -448,7 +471,11 @@ static int at91_adc_dma_start(struct iio_dev *indio_dev) for_each_set_bit(bit, indio_dev->active_scan_mask, indio_dev->num_channels) { - struct iio_chan_spec const *chan = indio_dev->channels + bit; + struct iio_chan_spec const *chan = + at91_adc_chan_get(indio_dev, bit); + + if (!chan) + continue; st->dma_st.rx_buf_sz += chan->scan_type.storagebits / 8; } @@ -526,8 +553,11 @@ static int at91_adc_buffer_predisable(struct iio_dev *indio_dev) */ for_each_set_bit(bit, indio_dev->active_scan_mask, indio_dev->num_channels) { - struct iio_chan_spec const *chan = indio_dev->channels + bit; + struct iio_chan_spec const *chan = + at91_adc_chan_get(indio_dev, bit); + if (!chan) + continue; if (st->dma_st.dma_chan) at91_adc_readl(st, chan->address); } @@ -587,8 +617,11 @@ static void at91_adc_trigger_handler_nodma(struct iio_dev *indio_dev, for_each_set_bit(bit, indio_dev->active_scan_mask, indio_dev->num_channels) { - struct iio_chan_spec const *chan = indio_dev->channels + bit; + struct iio_chan_spec const *chan = + at91_adc_chan_get(indio_dev, bit); + if (!chan) + continue; st->buffer[i] = at91_adc_readl(st, chan->address); i++; } -- 2.17.0

7 years, 7 months

1
0
0 0

patch "iio:kfifo_buf: check for uint overflow" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio:kfifo_buf: check for uint overflow to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 3d13de4b027d5f6276c0f9d3a264f518747d83f2 Mon Sep 17 00:00:00 2001 From: Martin Kelly <mkelly(a)xevo.com> Date: Mon, 26 Mar 2018 14:27:52 -0700 Subject: iio:kfifo_buf: check for uint overflow Currently, the following causes a kernel OOPS in memcpy: echo 1073741825 > buffer/length echo 1 > buffer/enable Note that using 1073741824 instead of 1073741825 causes "write error: Cannot allocate memory" but no OOPS. This is because 1073741824 == 2^30 and 1073741825 == 2^30+1. Since kfifo rounds up to the nearest power of 2, it will actually call kmalloc with roundup_pow_of_two(length) * bytes_per_datum. Using length == 1073741825 and bytes_per_datum == 2, we get: kmalloc(roundup_pow_of_two(1073741825) * 2 or kmalloc(2147483648 * 2) or kmalloc(4294967296) or kmalloc(UINT_MAX + 1) so this overflows to 0, causing kmalloc to return ZERO_SIZE_PTR and subsequent memcpy to fail once the device is enabled. Fix this by checking for overflow prior to allocating a kfifo. With this check added, the above code returns -EINVAL when enabling the buffer, rather than causing an OOPS. Signed-off-by: Martin Kelly <mkelly(a)xevo.com> cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/buffer/kfifo_buf.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/iio/buffer/kfifo_buf.c b/drivers/iio/buffer/kfifo_buf.c index ac622edf2486..70c302a93d7f 100644 --- a/drivers/iio/buffer/kfifo_buf.c +++ b/drivers/iio/buffer/kfifo_buf.c @@ -27,6 +27,13 @@ static inline int __iio_allocate_kfifo(struct iio_kfifo *buf, if ((length == 0) || (bytes_per_datum == 0)) return -EINVAL; + /* + * Make sure we don't overflow an unsigned int after kfifo rounds up to + * the next power of 2. + */ + if (roundup_pow_of_two(length) > UINT_MAX / bytes_per_datum) + return -EINVAL; + return __kfifo_alloc((struct __kfifo *)&buf->kf, length, bytes_per_datum, GFP_KERNEL); } -- 2.17.0

7 years, 7 months

1
0
0 0

patch "iio: adc: stm32-dfsdm: fix sample rate for div2 spi clock" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: stm32-dfsdm: fix sample rate for div2 spi clock to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From d58109dcf37fc9baec354385ec9fdcd8878d174d Mon Sep 17 00:00:00 2001 From: Fabrice Gasnier <fabrice.gasnier(a)st.com> Date: Tue, 13 Mar 2018 15:23:06 +0100 Subject: iio: adc: stm32-dfsdm: fix sample rate for div2 spi clock When channel clk source is set to "CLKOUT_F" or "CLKOUT_R" (e.g. div2), sample rate is currently set to half the requested value. Fixes: eca949800d2d ("IIO: ADC: add stm32 DFSDM support for PDM microphone") Signed-off-by: Fabrice Gasnier <fabrice.gasnier(a)st.com> Acked-by: Arnaud Pouliquen <arnaud.pouliquen(a)st.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/stm32-dfsdm-adc.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c index dc911b6fedd6..b28a716a23b2 100644 --- a/drivers/iio/adc/stm32-dfsdm-adc.c +++ b/drivers/iio/adc/stm32-dfsdm-adc.c @@ -771,7 +771,7 @@ static int stm32_dfsdm_write_raw(struct iio_dev *indio_dev, struct stm32_dfsdm_adc *adc = iio_priv(indio_dev); struct stm32_dfsdm_filter *fl = &adc->dfsdm->fl_list[adc->fl_id]; struct stm32_dfsdm_channel *ch = &adc->dfsdm->ch_list[chan->channel]; - unsigned int spi_freq = adc->spi_freq; + unsigned int spi_freq; int ret = -EINVAL; switch (mask) { @@ -785,8 +785,18 @@ static int stm32_dfsdm_write_raw(struct iio_dev *indio_dev, case IIO_CHAN_INFO_SAMP_FREQ: if (!val) return -EINVAL; - if (ch->src != DFSDM_CHANNEL_SPI_CLOCK_EXTERNAL) + + switch (ch->src) { + case DFSDM_CHANNEL_SPI_CLOCK_INTERNAL: spi_freq = adc->dfsdm->spi_master_freq; + break; + case DFSDM_CHANNEL_SPI_CLOCK_INTERNAL_DIV2_FALLING: + case DFSDM_CHANNEL_SPI_CLOCK_INTERNAL_DIV2_RISING: + spi_freq = adc->dfsdm->spi_master_freq / 2; + break; + default: + spi_freq = adc->spi_freq; + } if (spi_freq % val) dev_warn(&indio_dev->dev, -- 2.17.0

7 years, 7 months

1
0
0 0

patch "iio: adc: stm32-dfsdm: fix successive oversampling settings" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: stm32-dfsdm: fix successive oversampling settings to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 7531cf59bfa082769887ec70c2029838ea139f11 Mon Sep 17 00:00:00 2001 From: Fabrice Gasnier <fabrice.gasnier(a)st.com> Date: Tue, 13 Mar 2018 15:23:05 +0100 Subject: iio: adc: stm32-dfsdm: fix successive oversampling settings When doing successive oversampling settings, it may fail to update filter parameters silently: - First time oversampling is being set, it will be successful, as fl->res is 0 initially. - Next attempts with various oversamp value may return 0 (success), but keep previous filter parameters, due to 'res' never reaches above or equal current 'fl->res'. This is particularly true when setting sampling frequency (that relies on oversamp). Typical failure without error: - run 1st test @16kHz samp freq will succeed - run new test @8kHz will succeed as well - run new test @16kHz (again): sample rate will remain 8kHz without error Fixes: e2e6771c6462 ("IIO: ADC: add STM32 DFSDM sigma delta ADC support") Signed-off-by: Fabrice Gasnier <fabrice.gasnier(a)st.com> Acked-by: Arnaud Pouliquen <arnaud.pouliquen(a)st.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/stm32-dfsdm-adc.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c index 01422d11753c..dc911b6fedd6 100644 --- a/drivers/iio/adc/stm32-dfsdm-adc.c +++ b/drivers/iio/adc/stm32-dfsdm-adc.c @@ -144,6 +144,7 @@ static int stm32_dfsdm_set_osrs(struct stm32_dfsdm_filter *fl, * Leave as soon as if exact resolution if reached. * Otherwise the higher resolution below 32 bits is kept. */ + fl->res = 0; for (fosr = 1; fosr <= DFSDM_MAX_FL_OVERSAMPLING; fosr++) { for (iosr = 1; iosr <= DFSDM_MAX_INT_OVERSAMPLING; iosr++) { if (fast) @@ -193,7 +194,7 @@ static int stm32_dfsdm_set_osrs(struct stm32_dfsdm_filter *fl, } } - if (!fl->fosr) + if (!fl->res) return -EINVAL; return 0; -- 2.17.0

7 years, 7 months

1
0
0 0

patch "iio:buffer: make length types match kfifo types" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio:buffer: make length types match kfifo types to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From c043ec1ca5baae63726aae32abbe003192bc6eec Mon Sep 17 00:00:00 2001 From: Martin Kelly <mkelly(a)xevo.com> Date: Mon, 26 Mar 2018 14:27:51 -0700 Subject: iio:buffer: make length types match kfifo types Currently, we use int for buffer length and bytes_per_datum. However, kfifo uses unsigned int for length and size_t for element size. We need to make sure these matches or we will have bugs related to overflow (in the range between INT_MAX and UINT_MAX for length, for example). In addition, set_bytes_per_datum uses size_t while bytes_per_datum is an int, which would cause bugs for large values of bytes_per_datum. Change buffer length to use unsigned int and bytes_per_datum to use size_t. Signed-off-by: Martin Kelly <mkelly(a)xevo.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/buffer/industrialio-buffer-dma.c | 2 +- drivers/iio/buffer/kfifo_buf.c | 4 ++-- include/linux/iio/buffer_impl.h | 6 +++--- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/iio/buffer/industrialio-buffer-dma.c b/drivers/iio/buffer/industrialio-buffer-dma.c index 05e0c353e089..b32bf57910ca 100644 --- a/drivers/iio/buffer/industrialio-buffer-dma.c +++ b/drivers/iio/buffer/industrialio-buffer-dma.c @@ -587,7 +587,7 @@ EXPORT_SYMBOL_GPL(iio_dma_buffer_set_bytes_per_datum); * Should be used as the set_length callback for iio_buffer_access_ops * struct for DMA buffers. */ -int iio_dma_buffer_set_length(struct iio_buffer *buffer, int length) +int iio_dma_buffer_set_length(struct iio_buffer *buffer, unsigned int length) { /* Avoid an invalid state */ if (length < 2) diff --git a/drivers/iio/buffer/kfifo_buf.c b/drivers/iio/buffer/kfifo_buf.c index 047fe757ab97..ac622edf2486 100644 --- a/drivers/iio/buffer/kfifo_buf.c +++ b/drivers/iio/buffer/kfifo_buf.c @@ -22,7 +22,7 @@ struct iio_kfifo { #define iio_to_kfifo(r) container_of(r, struct iio_kfifo, buffer) static inline int __iio_allocate_kfifo(struct iio_kfifo *buf, - int bytes_per_datum, int length) + size_t bytes_per_datum, unsigned int length) { if ((length == 0) || (bytes_per_datum == 0)) return -EINVAL; @@ -67,7 +67,7 @@ static int iio_set_bytes_per_datum_kfifo(struct iio_buffer *r, size_t bpd) return 0; } -static int iio_set_length_kfifo(struct iio_buffer *r, int length) +static int iio_set_length_kfifo(struct iio_buffer *r, unsigned int length) { /* Avoid an invalid state */ if (length < 2) diff --git a/include/linux/iio/buffer_impl.h b/include/linux/iio/buffer_impl.h index b9e22b7e2f28..d1171db23742 100644 --- a/include/linux/iio/buffer_impl.h +++ b/include/linux/iio/buffer_impl.h @@ -53,7 +53,7 @@ struct iio_buffer_access_funcs { int (*request_update)(struct iio_buffer *buffer); int (*set_bytes_per_datum)(struct iio_buffer *buffer, size_t bpd); - int (*set_length)(struct iio_buffer *buffer, int length); + int (*set_length)(struct iio_buffer *buffer, unsigned int length); int (*enable)(struct iio_buffer *buffer, struct iio_dev *indio_dev); int (*disable)(struct iio_buffer *buffer, struct iio_dev *indio_dev); @@ -72,10 +72,10 @@ struct iio_buffer_access_funcs { */ struct iio_buffer { /** @length: Number of datums in buffer. */ - int length; + unsigned int length; /** @bytes_per_datum: Size of individual datum including timestamp. */ - int bytes_per_datum; + size_t bytes_per_datum; /** * @access: Buffer access functions associated with the -- 2.17.0

7 years, 7 months

1
0
0 0

patch "iio: ad7793: implement IIO_CHAN_INFO_SAMP_FREQ" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: ad7793: implement IIO_CHAN_INFO_SAMP_FREQ to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 490fba90a90eb7b741f57fefd2bcf2c1e11eb471 Mon Sep 17 00:00:00 2001 From: Michael Nosthoff <committed(a)heine.so> Date: Fri, 9 Mar 2018 16:13:52 +0100 Subject: iio: ad7793: implement IIO_CHAN_INFO_SAMP_FREQ This commit is a follow-up to changes made to ad_sigma_delta.h in staging: iio: ad7192: implement IIO_CHAN_INFO_SAMP_FREQ which broke ad7793 as it was not altered to match those changes. This driver predates the availability of IIO_CHAN_INFO_SAMP_FREQ attribute wherein usage has some advantages like it can be accessed by in-kernel consumers as well as reduces the code size. Therefore, use IIO_CHAN_INFO_SAMP_FREQ to implement the sampling_frequency attribute instead of using IIO_DEV_ATTR_SAMP_FREQ() macro. Move code from the functions associated with IIO_DEV_ATTR_SAMP_FREQ() into respective read and write hooks with the mask set to IIO_CHAN_INFO_SAMP_FREQ. Fixes: a13e831fcaa7 ("staging: iio: ad7192: implement IIO_CHAN_INFO_SAMP_FREQ") Signed-off-by: Michael Nosthoff <committed(a)heine.so> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad7793.c | 75 +++++++++++++--------------------------- 1 file changed, 24 insertions(+), 51 deletions(-) diff --git a/drivers/iio/adc/ad7793.c b/drivers/iio/adc/ad7793.c index 801afb61310b..d4bbe5b53318 100644 --- a/drivers/iio/adc/ad7793.c +++ b/drivers/iio/adc/ad7793.c @@ -348,55 +348,6 @@ static const u16 ad7793_sample_freq_avail[16] = {0, 470, 242, 123, 62, 50, 39, static const u16 ad7797_sample_freq_avail[16] = {0, 0, 0, 123, 62, 50, 0, 33, 0, 17, 16, 12, 10, 8, 6, 4}; -static ssize_t ad7793_read_frequency(struct device *dev, - struct device_attribute *attr, - char *buf) -{ - struct iio_dev *indio_dev = dev_to_iio_dev(dev); - struct ad7793_state *st = iio_priv(indio_dev); - - return sprintf(buf, "%d\n", - st->chip_info->sample_freq_avail[AD7793_MODE_RATE(st->mode)]); -} - -static ssize_t ad7793_write_frequency(struct device *dev, - struct device_attribute *attr, - const char *buf, - size_t len) -{ - struct iio_dev *indio_dev = dev_to_iio_dev(dev); - struct ad7793_state *st = iio_priv(indio_dev); - long lval; - int i, ret; - - ret = kstrtol(buf, 10, &lval); - if (ret) - return ret; - - if (lval == 0) - return -EINVAL; - - for (i = 0; i < 16; i++) - if (lval == st->chip_info->sample_freq_avail[i]) - break; - if (i == 16) - return -EINVAL; - - ret = iio_device_claim_direct_mode(indio_dev); - if (ret) - return ret; - st->mode &= ~AD7793_MODE_RATE(-1); - st->mode |= AD7793_MODE_RATE(i); - ad_sd_write_reg(&st->sd, AD7793_REG_MODE, sizeof(st->mode), st->mode); - iio_device_release_direct_mode(indio_dev); - - return len; -} - -static IIO_DEV_ATTR_SAMP_FREQ(S_IWUSR | S_IRUGO, - ad7793_read_frequency, - ad7793_write_frequency); - static IIO_CONST_ATTR_SAMP_FREQ_AVAIL( "470 242 123 62 50 39 33 19 17 16 12 10 8 6 4"); @@ -424,7 +375,6 @@ static IIO_DEVICE_ATTR_NAMED(in_m_in_scale_available, ad7793_show_scale_available, NULL, 0); static struct attribute *ad7793_attributes[] = { - &iio_dev_attr_sampling_frequency.dev_attr.attr, &iio_const_attr_sampling_frequency_available.dev_attr.attr, &iio_dev_attr_in_m_in_scale_available.dev_attr.attr, NULL @@ -435,7 +385,6 @@ static const struct attribute_group ad7793_attribute_group = { }; static struct attribute *ad7797_attributes[] = { - &iio_dev_attr_sampling_frequency.dev_attr.attr, &iio_const_attr_sampling_frequency_available_ad7797.dev_attr.attr, NULL }; @@ -505,6 +454,10 @@ static int ad7793_read_raw(struct iio_dev *indio_dev, *val -= offset; } return IIO_VAL_INT; + case IIO_CHAN_INFO_SAMP_FREQ: + *val = st->chip_info + ->sample_freq_avail[AD7793_MODE_RATE(st->mode)]; + return IIO_VAL_INT; } return -EINVAL; } @@ -542,6 +495,26 @@ static int ad7793_write_raw(struct iio_dev *indio_dev, break; } break; + case IIO_CHAN_INFO_SAMP_FREQ: + if (!val) { + ret = -EINVAL; + break; + } + + for (i = 0; i < 16; i++) + if (val == st->chip_info->sample_freq_avail[i]) + break; + + if (i == 16) { + ret = -EINVAL; + break; + } + + st->mode &= ~AD7793_MODE_RATE(-1); + st->mode |= AD7793_MODE_RATE(i); + ad_sd_write_reg(&st->sd, AD7793_REG_MODE, sizeof(st->mode), + st->mode); + break; default: ret = -EINVAL; } -- 2.17.0

7 years, 7 months

1
0
0 0

[PATCH 5/5] radix tree: fix multi-order iteration race

by Ross Zwisler

Fix a race in the multi-order iteration code which causes the kernel to hit a GP fault. This was first seen with a production v4.15 based kernel (4.15.6-300.fc27.x86_64) utilizing a DAX workload which used order 9 PMD DAX entries. The race has to do with how we tear down multi-order sibling entries when we are removing an item from the tree. Remember for example that an order 2 entry looks like this: struct radix_tree_node.slots[] = [entry][sibling][sibling][sibling] where 'entry' is in some slot in the struct radix_tree_node, and the three slots following 'entry' contain sibling pointers which point back to 'entry.' When we delete 'entry' from the tree, we call : radix_tree_delete() radix_tree_delete_item() __radix_tree_delete() replace_slot() replace_slot() first removes the siblings in order from the first to the last, then at then replaces 'entry' with NULL. This means that for a brief period of time we end up with one or more of the siblings removed, so: struct radix_tree_node.slots[] = [entry][NULL][sibling][sibling] This causes an issue if you have a reader iterating over the slots in the tree via radix_tree_for_each_slot() while only under rcu_read_lock()/rcu_read_unlock() protection. This is a common case in mm/filemap.c. The issue is that when __radix_tree_next_slot() => skip_siblings() tries to skip over the sibling entries in the slots, it currently does so with an exact match on the slot directly preceding our current slot. Normally this works: V preceding slot struct radix_tree_node.slots[] = [entry][sibling][sibling][sibling] ^ current slot This lets you find the first sibling, and you skip them all in order. But in the case where one of the siblings is NULL, that slot is skipped and then our sibling detection is interrupted: V preceding slot struct radix_tree_node.slots[] = [entry][NULL][sibling][sibling] ^ current slot This means that the sibling pointers aren't recognized since they point all the way back to 'entry', so we think that they are normal internal radix tree pointers. This causes us to think we need to walk down to a struct radix_tree_node starting at the address of 'entry'. In a real running kernel this will crash the thread with a GP fault when you try and dereference the slots in your broken node starting at 'entry'. We fix this race by fixing the way that skip_siblings() detects sibling nodes. Instead of testing against the preceding slot we instead look for siblings via is_sibling_entry() which compares against the position of the struct radix_tree_node.slots[] array. This ensures that sibling entries are properly identified, even if they are no longer contiguous with the 'entry' they point to. Signed-off-by: Ross Zwisler <ross.zwisler(a)linux.intel.com> Reported-by: CR, Sapthagirish <sapthagirish.cr(a)intel.com> Fixes: commit 148deab223b2 ("radix-tree: improve multiorder iterators") Cc: <stable(a)vger.kernel.org> --- lib/radix-tree.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/lib/radix-tree.c b/lib/radix-tree.c index da9e10c827df..43e0cbedc3a0 100644 --- a/lib/radix-tree.c +++ b/lib/radix-tree.c @@ -1612,11 +1612,9 @@ static void set_iter_tags(struct radix_tree_iter *iter, static void __rcu **skip_siblings(struct radix_tree_node **nodep, void __rcu **slot, struct radix_tree_iter *iter) { - void *sib = node_to_entry(slot - 1); - while (iter->index < iter->next_index) { *nodep = rcu_dereference_raw(*slot); - if (*nodep && *nodep != sib) + if (*nodep && !is_sibling_entry(iter->node, *nodep)) return slot; slot++; iter->index = __radix_tree_iter_add(iter, 1); @@ -1631,7 +1629,7 @@ void __rcu **__radix_tree_next_slot(void __rcu **slot, struct radix_tree_iter *iter, unsigned flags) { unsigned tag = flags & RADIX_TREE_ITER_TAG_MASK; - struct radix_tree_node *node = rcu_dereference_raw(*slot); + struct radix_tree_node *node; slot = skip_siblings(&node, slot, iter); -- 2.14.3

7 years, 7 months

2
2
0 0

Please apply 3f1e53abff84c (" netfilter: ebtables: don't attempt to allocate 0-sized compat array") to v4.14.y and later

by Guenter Roeck

Hi Greg, Commit 3f1e53abff84c fixes commit 7d7d7e02111e9 ("("netfilter: compat: reject huge allocation requests"), which has found its way into 4.14.y and 4.16.y. This causes syzcaller hiccups at least in 4.14.y (more specifically chromeos-4.14). Please apply 3f1e53abff84c to v4.14.y and v4.16.y to fix the problem. Copying Dave and netdev in case he wants to handle it. Sorry for the noise if this has already been queued. Thanks, Guenter

7 years, 7 months

2
1
0 0

v4.14.40 build: 0 failures 1 warnings (v4.14.40)

by Build bot for Mark Brown

Tree/Branch: v4.14.40 Git describe: v4.14.40 Commit: fc72a41711 Linux 4.14.40 Build Time: 98 min 2 sec Passed: 11 / 11 (100.00 %) Failed: 0 / 11 ( 0.00 %) Errors: 0 Warnings: 1 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 1 warnings 0 mismatches : x86_64-allmodconfig ------------------------------------------------------------------------------- Warnings Summary: 1 1 drivers/target/iscsi/.tmp_iscsi_target.o: warning: objtool: iscsit_handle_task_mgt_cmd()+0x78f: sibling call from callable instruction with modified stack frame =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: drivers/target/iscsi/.tmp_iscsi_target.o: warning: objtool: iscsit_handle_task_mgt_cmd()+0x78f: sibling call from callable instruction with modified stack frame ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

7 years, 7 months

1
0
0 0

[PATCH 0/2] fixes for 4.9.96

by Jarkko Sakkinen

Decided to add Enric's commit because it is also a bug fix instead of modifying Chris commit. Chris Chiu (1): tpm: self test failure should not cause suspend to fail Enric Balletbo i Serra (1): tpm: do not suspend/resume if power stays on drivers/char/tpm/tpm-interface.c | 7 +++++++ drivers/char/tpm/tpm.h | 2 ++ drivers/char/tpm/tpm_of.c | 3 +++ 3 files changed, 12 insertions(+) -- 2.17.0

7 years, 7 months

3
7
0 0

[PATCH v9 0/9] dax: fix dma vs truncate/hole-punch

by Dan Williams

Changes since v8 [1]: * Rebase on v4.17-rc2 * Fix get_user_pages_fast() for ZONE_DEVICE pages to revalidate the pte, pmd, pud after taking references (Jan) * Kill dax_layout_lock(). With get_user_pages_fast() for ZONE_DEVICE fixed we can then rely on the {pte,pmd}_lock to synchronize dax_layout_busy_page() vs new page references (Jan) * Hold the iolock over repeated invocations of dax_layout_busy_page() to enable truncate/hole-punch to make forward progress in the presence of a constant stream of new direct-I/O requests (Jan). [1]: https://lists.01.org/pipermail/linux-nvdimm/2018-March/015058.html --- Background: get_user_pages() in the filesystem pins file backed memory pages for access by devices performing dma. However, it only pins the memory pages not the page-to-file offset association. If a file is truncated the pages are mapped out of the file and dma may continue indefinitely into a page that is owned by a device driver. This breaks coherency of the file vs dma, but the assumption is that if userspace wants the file-space truncated it does not matter what data is inbound from the device, it is not relevant anymore. The only expectation is that dma can safely continue while the filesystem reallocates the block(s). Problem: This expectation that dma can safely continue while the filesystem changes the block map is broken by dax. With dax the target dma page *is* the filesystem block. The model of leaving the page pinned for dma, but truncating the file block out of the file, means that the filesytem is free to reallocate a block under active dma to another file and now the expected data-incoherency situation has turned into active data-corruption. Solution: Defer all filesystem operations (fallocate(), truncate()) on a dax mode file while any page/block in the file is under active dma. This solution assumes that dma is transient. Cases where dma operations are known to not be transient, like RDMA, have been explicitly disabled via commits like 5f1d43de5416 "IB/core: disable memory registration of filesystem-dax vmas". The dax_layout_busy_page() routine is called by filesystems with a lock held against mm faults (i_mmap_lock) to find pinned / busy dax pages. The process of looking up a busy page invalidates all mappings to trigger any subsequent get_user_pages() to block on i_mmap_lock. The filesystem continues to call dax_layout_busy_page() until it finally returns no more active pages. This approach assumes that the page pinning is transient, if that assumption is violated the system would have likely hung from the uncompleted I/O. --- Dan Williams (9): dax, dm: introduce ->fs_{claim,release}() dax_device infrastructure mm, dax: enable filesystems to trigger dev_pagemap ->page_free callbacks memremap: split devm_memremap_pages() and memremap() infrastructure mm, dev_pagemap: introduce CONFIG_DEV_PAGEMAP_OPS mm: fix __gup_device_huge vs unmap mm, fs, dax: handle layout changes to pinned dax mappings xfs: prepare xfs_break_layouts() to be called with XFS_MMAPLOCK_EXCL xfs: prepare xfs_break_layouts() for another layout type xfs, dax: introduce xfs_break_dax_layouts() drivers/dax/super.c | 99 ++++++++++++++++++++-- drivers/md/dm.c | 57 +++++++++++++ drivers/nvdimm/pmem.c | 3 - fs/Kconfig | 2 fs/dax.c | 97 +++++++++++++++++++++ fs/ext2/super.c | 6 + fs/ext4/super.c | 6 + fs/xfs/xfs_file.c | 72 +++++++++++++++- fs/xfs/xfs_inode.h | 16 ++++ fs/xfs/xfs_ioctl.c | 8 -- fs/xfs/xfs_iops.c | 16 ++-- fs/xfs/xfs_pnfs.c | 16 ++-- fs/xfs/xfs_pnfs.h | 6 + fs/xfs/xfs_super.c | 20 ++-- include/linux/dax.h | 71 +++++++++++++++- include/linux/memremap.h | 25 ++---- include/linux/mm.h | 71 ++++++++++++---- kernel/Makefile | 3 - kernel/iomem.c | 167 +++++++++++++++++++++++++++++++++++++ kernel/memremap.c | 208 ++++++---------------------------------------- mm/Kconfig | 5 + mm/gup.c | 37 ++++++-- mm/hmm.c | 13 --- mm/swap.c | 3 - 24 files changed, 730 insertions(+), 297 deletions(-) create mode 100644 kernel/iomem.c

7 years, 7 months

3
4
0 0

Linux 4.16.8

by Greg KH

I'm announcing the release of the 4.16.8 kernel. All users of the 4.16 kernel series must upgrade. The updated 4.16.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.16.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h ------------ Documentation/arm64/silicon-errata.txt | 1 Makefile | 2 arch/arm64/Kconfig | 14 arch/arm64/include/asm/assembler.h | 40 arch/arm64/include/asm/cputype.h | 2 arch/arm64/mm/proc.S | 5 arch/x86/kernel/tsc.c | 22 arch/x86/kvm/lapic.c | 37 drivers/acpi/button.c | 24 drivers/gpu/drm/bridge/dumb-vga-dac.c | 4 drivers/gpu/drm/vc4/vc4_crtc.c | 46 - drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 1 drivers/infiniband/core/ucma.c | 2 drivers/infiniband/hw/cxgb4/cq.c | 11 drivers/infiniband/hw/cxgb4/device.c | 9 drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 6 drivers/infiniband/hw/cxgb4/qp.c | 4 drivers/infiniband/hw/cxgb4/resource.c | 26 drivers/infiniband/hw/hfi1/driver.c | 19 drivers/infiniband/hw/hfi1/hfi.h | 8 drivers/infiniband/hw/hfi1/init.c | 2 drivers/infiniband/hw/hfi1/pcie.c | 3 drivers/infiniband/hw/hfi1/ruc.c | 50 - drivers/infiniband/hw/hfi1/ud.c | 4 drivers/infiniband/hw/mlx4/qp.c | 3 drivers/infiniband/hw/mlx5/Kconfig | 1 drivers/infiniband/hw/mlx5/mr.c | 32 drivers/infiniband/hw/mlx5/qp.c | 22 drivers/input/input-leds.c | 8 drivers/input/touchscreen/atmel_mxt_ts.c | 9 drivers/irqchip/qcom-irq-combiner.c | 4 drivers/net/usb/qmi_wwan.c | 1 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 15 drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 11 drivers/net/wireless/realtek/rtlwifi/wifi.h | 5 drivers/platform/x86/Kconfig | 2 drivers/platform/x86/asus-wireless.c | 4 drivers/target/target_core_iblock.c | 8 drivers/usb/core/config.c | 4 drivers/usb/dwc3/gadget.c | 2 drivers/usb/host/xhci.c | 1 drivers/usb/musb/musb_gadget.c | 3 drivers/usb/musb/musb_host.c | 4 drivers/usb/serial/option.c | 451 +++------- drivers/usb/serial/visor.c | 69 - fs/btrfs/extent-tree.c | 7 fs/xfs/xfs_file.c | 14 kernel/time/clocksource.c | 57 - kernel/trace/trace_uprobe.c | 24 kernel/tracepoint.c | 4 lib/errseq.c | 23 lib/swiotlb.c | 2 sound/core/pcm_compat.c | 2 sound/core/seq/seq_virmidi.c | 4 sound/drivers/aloop.c | 29 sound/firewire/amdtp-stream.c | 5 sound/pci/hda/patch_realtek.c | 2 tools/power/acpi/Makefile.config | 1 tools/testing/selftests/firmware/fw_filesystem.sh | 6 59 files changed, 673 insertions(+), 508 deletions(-) Agustin Vega-Frias (1): irqchip/qcom: Fix check for spurious interrupts Alan Stern (1): USB: Accept bulk endpoints with 1024-byte maxpacket Anthoine Bourgeois (1): KVM: x86: remove APIC Timer periodic/oneshot spikes Ard Biesheuvel (1): ACPI / button: make module loadable when booted in non-ACPI mode Ben Hutchings (1): test_firmware: fix setting old custom fw path back on exit, second try Bharat Potnuri (1): iw_cxgb4: Atomically flush per QP HW CQEs Bin Liu (2): usb: musb: host: fix potential NULL pointer dereference usb: musb: trace: fix NULL pointer dereference in musb_g_tx() Boris Brezillon (1): drm/vc4: Make sure vc4_bo_{inc,dec}_usecnt() calls are balanced Bryant G Ly (1): scsi: target: Fix fortify_panic kernel exception Danit Goldberg (1): IB/mlx5: Use unlimited rate when static rate is not supported Darrick J. Wong (1): xfs: prevent creating negative-sized file via INSERT_RANGE Dmitry Torokhov (1): Input: leds - fix out of bound access Greg Kroah-Hartman (2): USB: serial: visor: handle potential invalid device configuration Linux 4.16.8 Jiri Slaby (1): tools: power/acpi, revert to LD = gcc Johan Hovold (1): USB: serial: option: reimplement interface masking João Paulo Rechi Vita (1): platform/x86: asus-wireless: Fix NULL pointer dereference Leon Romanovsky (3): RDMA/mlx5: Fix multiple NULL-ptr deref errors in rereg_mr flow RDMA/mlx4: Add missed RSS hash inner header flag RDMA/mlx5: Protect from shift operand overflow Mario Limonciello (1): platform/x86: Kconfig: Fix dell-laptop dependency chain. Mathias Nyman (1): xhci: Fix use-after-free in xhci_free_virt_device Mathieu Desnoyers (1): tracepoint: Do not warn on ENOMEM Matthew Wilcox (1): errseq: Always report a writeback error once Mayank Rana (1): usb: dwc3: gadget: Fix list_del corruption in dwc3_ep_dequeue Michel Dänzer (1): swiotlb: fix inversed DMA_ATTR_NO_WARN test Mike Marciniszyn (2): IB/hfi1: Fix handling of FECN marked multicast packet IB/hfi1: Fix loss of BECN with AHG Peter Zijlstra (5): x86/tsc: Always unregister clocksource_tsc_early x86/tsc: Fix mark_tsc_unstable() clocksource: Allow clocksource_mark_unstable() on unregistered clocksources clocksource: Initialize cs->wd_list clocksource: Consistent de-rate when marking unstable Ping-Ke Shih (1): rtlwifi: cleanup 8723be ant_sel definition Raju Rangoju (1): RDMA/cxgb4: release hw resources on device removal Randy Dunlap (1): infiniband: mlx5: fix build errors when INFINIBAND_USER_ACCESS=m Robert Rosengren (1): ALSA: aloop: Mark paused device as inactive Roland Dreier (1): RDMA/ucma: Allow resolving address w/o specifying source address SZ Lin (林上智) (2): NET: usb: qmi_wwan: add support for ublox R410M PID 0x90b2 USB: serial: option: adding support for ublox R410M Sean Paul (1): drm/bridge: vga-dac: Fix edid memory leak Sebastian Sanchez (1): IB/hfi1: Fix NULL pointer dereference when invalid num_vls is used Song Liu (1): tracing: Fix bad use of igrab in trace_uprobe.c Suzuki K Poulose (1): arm64: Add work around for Arm Cortex-A55 Erratum 1024718 Takashi Iwai (4): ALSA: hda - Fix incorrect usage of IS_REACHABLE() ALSA: pcm: Check PCM state at xfern compat ioctl ALSA: seq: Fix races at MIDI encoding in snd_virmidi_output_trigger() ALSA: aloop: Add missing cable lock to ctl API callbacks Takashi Sakamoto (1): ALSA: dice: fix kernel NULL pointer dereference due to invalid calculation for array index Thomas Hellstrom (1): drm/vmwgfx: Fix a buffer object leak Vittorio Gambaletta (VittGam) (1): Input: atmel_mxt_ts - add touchpad button mapping for Samsung Chromebook Pro ethanwu (1): btrfs: Take trans lock before access running trans in check_delayed_ref

7 years, 7 months

1
1
0 0

Linux 4.14.40

by Greg KH

I'm announcing the release of the 4.14.40 kernel. All users of the 4.14 kernel series must upgrade. The updated 4.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h ------------ Makefile | 2 drivers/acpi/button.c | 24 drivers/crypto/talitos.c | 41 drivers/gpu/drm/bridge/dumb-vga-dac.c | 4 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 1 drivers/infiniband/core/ucma.c | 2 drivers/infiniband/hw/cxgb4/cq.c | 11 drivers/infiniband/hw/cxgb4/device.c | 9 drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 6 drivers/infiniband/hw/cxgb4/qp.c | 4 drivers/infiniband/hw/cxgb4/resource.c | 26 drivers/infiniband/hw/hfi1/driver.c | 19 drivers/infiniband/hw/hfi1/hfi.h | 8 drivers/infiniband/hw/hfi1/init.c | 2 drivers/infiniband/hw/hfi1/pcie.c | 3 drivers/infiniband/hw/hfi1/ruc.c | 50 - drivers/infiniband/hw/hfi1/ud.c | 4 drivers/infiniband/hw/mlx5/mr.c | 32 drivers/infiniband/hw/mlx5/qp.c | 22 drivers/infiniband/ulp/ipoib/ipoib_cm.c | 3 drivers/input/input-leds.c | 8 drivers/input/touchscreen/atmel_mxt_ts.c | 9 drivers/irqchip/qcom-irq-combiner.c | 4 drivers/net/geneve.c | 14 drivers/net/usb/qmi_wwan.c | 1 drivers/net/vxlan.c | 6 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 15 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h | 1 drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.c | 6 drivers/net/wireless/realtek/rtlwifi/btcoexist/rtl_btc.h | 1 drivers/net/wireless/realtek/rtlwifi/rtl8723be/hw.c | 11 drivers/net/wireless/realtek/rtlwifi/wifi.h | 6 drivers/platform/x86/asus-wireless.c | 4 drivers/target/target_core_iblock.c | 8 drivers/usb/core/config.c | 4 drivers/usb/dwc3/gadget.c | 2 drivers/usb/musb/musb_gadget.c | 3 drivers/usb/musb/musb_host.c | 4 drivers/usb/serial/option.c | 448 +++------- drivers/usb/serial/visor.c | 69 - fs/xfs/xfs_file.c | 14 include/net/dst.h | 8 kernel/trace/trace_uprobe.c | 24 kernel/tracepoint.c | 4 lib/errseq.c | 25 mm/percpu.c | 1 net/ipv4/ip_tunnel.c | 3 net/ipv4/ip_vti.c | 2 net/ipv6/ip6_tunnel.c | 5 net/ipv6/ip6_vti.c | 2 net/ipv6/sit.c | 4 sound/core/pcm_compat.c | 2 sound/core/seq/seq_virmidi.c | 4 sound/drivers/aloop.c | 29 sound/firewire/amdtp-stream.c | 5 sound/pci/hda/patch_realtek.c | 2 tools/testing/selftests/firmware/fw_filesystem.sh | 6 57 files changed, 546 insertions(+), 491 deletions(-) Agustin Vega-Frias (1): irqchip/qcom: Fix check for spurious interrupts Alan Stern (1): USB: Accept bulk endpoints with 1024-byte maxpacket Ard Biesheuvel (1): ACPI / button: make module loadable when booted in non-ACPI mode Ben Hutchings (1): test_firmware: fix setting old custom fw path back on exit, second try Bharat Potnuri (1): iw_cxgb4: Atomically flush per QP HW CQEs Bin Liu (2): usb: musb: host: fix potential NULL pointer dereference usb: musb: trace: fix NULL pointer dereference in musb_g_tx() Bryant G Ly (1): scsi: target: Fix fortify_panic kernel exception Danit Goldberg (1): IB/mlx5: Use unlimited rate when static rate is not supported Darrick J. Wong (1): xfs: prevent creating negative-sized file via INSERT_RANGE Dmitry Torokhov (1): Input: leds - fix out of bound access Greg Kroah-Hartman (2): USB: serial: visor: handle potential invalid device configuration Linux 4.14.40 Johan Hovold (1): USB: serial: option: reimplement interface masking João Paulo Rechi Vita (1): platform/x86: asus-wireless: Fix NULL pointer dereference Kristian Evensen (1): USB: serial: option: Add support for Quectel EP06 LEROY Christophe (1): crypto: talitos - fix IPsec cipher in length Leon Romanovsky (2): RDMA/mlx5: Fix multiple NULL-ptr deref errors in rereg_mr flow RDMA/mlx5: Protect from shift operand overflow Mathieu Desnoyers (1): tracepoint: Do not warn on ENOMEM Matthew Wilcox (1): errseq: Always report a writeback error once Mayank Rana (1): usb: dwc3: gadget: Fix list_del corruption in dwc3_ep_dequeue Mike Marciniszyn (2): IB/hfi1: Fix handling of FECN marked multicast packet IB/hfi1: Fix loss of BECN with AHG Nicolas Dichtel (1): net: don't call update_pmtu unconditionally Ping-Ke Shih (2): rtlwifi: btcoex: Add power_on_setting routine rtlwifi: cleanup 8723be ant_sel definition Raju Rangoju (1): RDMA/cxgb4: release hw resources on device removal Robert Rosengren (1): ALSA: aloop: Mark paused device as inactive Roland Dreier (1): RDMA/ucma: Allow resolving address w/o specifying source address SZ Lin (林上智) (2): NET: usb: qmi_wwan: add support for ublox R410M PID 0x90b2 USB: serial: option: adding support for ublox R410M Sean Paul (1): drm/bridge: vga-dac: Fix edid memory leak Sebastian Sanchez (1): IB/hfi1: Fix NULL pointer dereference when invalid num_vls is used Song Liu (1): tracing: Fix bad use of igrab in trace_uprobe.c Takashi Iwai (4): ALSA: hda - Fix incorrect usage of IS_REACHABLE() ALSA: pcm: Check PCM state at xfern compat ioctl ALSA: seq: Fix races at MIDI encoding in snd_virmidi_output_trigger() ALSA: aloop: Add missing cable lock to ctl API callbacks Takashi Sakamoto (1): ALSA: dice: fix kernel NULL pointer dereference due to invalid calculation for array index Tejun Heo (1): percpu: include linux/sched.h for cond_resched() Thomas Hellstrom (1): drm/vmwgfx: Fix a buffer object leak Vittorio Gambaletta (VittGam) (1): Input: atmel_mxt_ts - add touchpad button mapping for Samsung Chromebook Pro Xin Long (1): geneve: update skb dst pmtu on tx path

7 years, 7 months

1
1
0 0

Linux 4.9.99

by Greg KH

I'm announcing the release of the 4.9.99 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h ------------ Documentation/virtual/kvm/api.txt | 9 Documentation/virtual/kvm/arm/psci.txt | 30 + Makefile | 2 arch/arm/include/asm/kvm_host.h | 3 arch/arm/include/uapi/asm/kvm.h | 6 arch/arm/kvm/guest.c | 13 arch/arm/kvm/psci.c | 60 ++ arch/arm64/include/asm/kvm_host.h | 3 arch/arm64/include/uapi/asm/kvm.h | 6 arch/arm64/kvm/guest.c | 14 arch/s390/include/asm/facility.h | 2 drivers/crypto/talitos.c | 41 +- drivers/gpu/drm/bridge/dumb-vga-dac.c | 4 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 1 drivers/infiniband/core/ucma.c | 2 drivers/infiniband/hw/cxgb4/device.c | 9 drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 4 drivers/infiniband/hw/cxgb4/resource.c | 26 + drivers/infiniband/hw/hfi1/init.c | 2 drivers/infiniband/hw/hfi1/pcie.c | 3 drivers/infiniband/hw/mlx5/qp.c | 22 - drivers/input/input-leds.c | 8 drivers/input/touchscreen/atmel_mxt_ts.c | 9 drivers/net/usb/qmi_wwan.c | 1 drivers/platform/x86/asus-wireless.c | 4 drivers/tty/serial/imx.c | 14 drivers/usb/core/config.c | 4 drivers/usb/musb/musb_gadget.c | 3 drivers/usb/musb/musb_host.c | 4 drivers/usb/serial/option.c | 448 +++++++--------------- drivers/usb/serial/visor.c | 69 +-- fs/xfs/xfs_file.c | 14 include/kvm/arm_psci.h | 16 kernel/bpf/arraymap.c | 2 kernel/bpf/hashtab.c | 9 kernel/bpf/syscall.c | 20 kernel/events/core.c | 2 kernel/tracepoint.c | 4 mm/percpu.c | 1 sound/core/pcm_compat.c | 2 sound/core/seq/seq_virmidi.c | 4 sound/drivers/aloop.c | 29 + tools/testing/selftests/firmware/fw_filesystem.sh | 6 43 files changed, 529 insertions(+), 406 deletions(-) Alan Stern (1): USB: Accept bulk endpoints with 1024-byte maxpacket Ben Hutchings (1): test_firmware: fix setting old custom fw path back on exit, second try Bin Liu (2): usb: musb: host: fix potential NULL pointer dereference usb: musb: trace: fix NULL pointer dereference in musb_g_tx() Danit Goldberg (1): IB/mlx5: Use unlimited rate when static rate is not supported Darrick J. Wong (1): xfs: prevent creating negative-sized file via INSERT_RANGE Dmitry Torokhov (1): Input: leds - fix out of bound access Greg Kroah-Hartman (2): USB: serial: visor: handle potential invalid device configuration Linux 4.9.99 Heiko Carstens (1): s390/facilites: use stfle_fac_list array size for MAX_FACILITY_BIT Johan Hovold (1): USB: serial: option: reimplement interface masking João Paulo Rechi Vita (1): platform/x86: asus-wireless: Fix NULL pointer dereference Kristian Evensen (1): USB: serial: option: Add support for Quectel EP06 LEROY Christophe (1): crypto: talitos - fix IPsec cipher in length Leon Romanovsky (1): RDMA/mlx5: Protect from shift operand overflow Marc Zyngier (1): arm/arm64: KVM: Add PSCI version selection API Mathieu Desnoyers (1): tracepoint: Do not warn on ENOMEM Raju Rangoju (1): RDMA/cxgb4: release hw resources on device removal Robert Rosengren (1): ALSA: aloop: Mark paused device as inactive Roland Dreier (1): RDMA/ucma: Allow resolving address w/o specifying source address SZ Lin (林上智) (2): NET: usb: qmi_wwan: add support for ublox R410M PID 0x90b2 USB: serial: option: adding support for ublox R410M Sean Paul (1): drm/bridge: vga-dac: Fix edid memory leak Sebastian Sanchez (1): IB/hfi1: Fix NULL pointer dereference when invalid num_vls is used Takashi Iwai (3): ALSA: pcm: Check PCM state at xfern compat ioctl ALSA: seq: Fix races at MIDI encoding in snd_virmidi_output_trigger() ALSA: aloop: Add missing cable lock to ctl API callbacks Tan Xiaojun (1): perf/core: Fix the perf_cpu_time_max_percent check Tejun Heo (1): percpu: include linux/sched.h for cond_resched() Teng Qin (1): bpf: map_get_next_key to return first key on NULL Thomas Hellstrom (1): drm/vmwgfx: Fix a buffer object leak Uwe Kleine-König (1): serial: imx: ensure UCR3 and UFCR are setup correctly Vittorio Gambaletta (VittGam) (1): Input: atmel_mxt_ts - add touchpad button mapping for Samsung Chromebook Pro

7 years, 7 months

1
1
0 0

[PATCH] sched/schedutil: Don't set next_freq to UINT_MAX

by Viresh Kumar

The schedutil driver sets sg_policy->next_freq to UINT_MAX on certain occasions: - In sugov_start(), when the schedutil governor is started for a group of CPUs. - And whenever we need to force a freq update before rate-limit duration, which happens when: - there is an update in cpufreq policy limits. - Or when the utilization of DL scheduling class increases. In return, get_next_freq() doesn't return a cached next_freq value but instead recalculates the next frequency. This has some side effects though and may significantly delay a required increase in frequency. In sugov_update_single() we try to avoid decreasing frequency if the CPU has not been idle recently. Consider this scenario, the available range of frequencies for a CPU are from 800 MHz to 2.5 GHz and current frequency is 800 MHz. From one of the call paths sg_policy->need_freq_update is set to true and hence sg_policy->next_freq is set to UINT_MAX. Now if the CPU had been busy, next_f will always be less than UINT_MAX, whatever the value of next_f is. And so even when we wanted to increase the frequency, we will overwrite next_f with UINT_MAX and will not change the frequency eventually. This will continue until the time CPU stays busy. This isn't cross checked with any specific test cases, but rather based on general code review. Fix that by not resetting the sg_policy->need_freq_update flag from sugov_should_update_freq() but get_next_freq() and we wouldn't need to overwrite sg_policy->next_freq anymore. Cc: 4.12+ <stable(a)vger.kernel.org> # 4.12+ Fixes: b7eaf1aab9f8 ("cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely") Signed-off-by: Viresh Kumar <viresh.kumar(a)linaro.org> --- kernel/sched/cpufreq_schedutil.c | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c index d2c6083304b4..daaca23697dc 100644 --- a/kernel/sched/cpufreq_schedutil.c +++ b/kernel/sched/cpufreq_schedutil.c @@ -95,15 +95,8 @@ static bool sugov_should_update_freq(struct sugov_policy *sg_policy, u64 time) if (sg_policy->work_in_progress) return false; - if (unlikely(sg_policy->need_freq_update)) { - sg_policy->need_freq_update = false; - /* - * This happens when limits change, so forget the previous - * next_freq value and force an update. - */ - sg_policy->next_freq = UINT_MAX; + if (unlikely(sg_policy->need_freq_update)) return true; - } delta_ns = time - sg_policy->last_freq_update_time; @@ -165,8 +158,10 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy, freq = (freq + (freq >> 2)) * util / max; - if (freq == sg_policy->cached_raw_freq && sg_policy->next_freq != UINT_MAX) + if (freq == sg_policy->cached_raw_freq && !sg_policy->need_freq_update) return sg_policy->next_freq; + + sg_policy->need_freq_update = false; sg_policy->cached_raw_freq = freq; return cpufreq_driver_resolve_freq(policy, freq); } @@ -670,7 +665,7 @@ static int sugov_start(struct cpufreq_policy *policy) sg_policy->freq_update_delay_ns = sg_policy->tunables->rate_limit_us * NSEC_PER_USEC; sg_policy->last_freq_update_time = 0; - sg_policy->next_freq = UINT_MAX; + sg_policy->next_freq = 0; sg_policy->work_in_progress = false; sg_policy->need_freq_update = false; sg_policy->cached_raw_freq = 0; -- 2.15.0.194.g9af6a3dea062

7 years, 7 months

2
7
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror