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

+ mm-memcg-slab-call-flush_memcg_workqueue-only-if-memcg-workqueue-is-valid.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm: memcg/slab: call flush_memcg_workqueue() only if memcg workqueue is valid has been added to the -mm tree. Its filename is mm-memcg-slab-call-flush_memcg_workqueue-only-if-memcg-workqueue-is-valid.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-memcg-slab-call-flush_memcg_wor… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-memcg-slab-call-flush_memcg_wor… 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: Adrian Huang <ahuang12(a)lenovo.com> Subject: mm: memcg/slab: call flush_memcg_workqueue() only if memcg workqueue is valid When booting with amd_iommu=off, the following WARNING message appears: AMD-Vi: AMD IOMMU disabled on kernel command-line ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/workqueue.c:2772 flush_workqueue+0x42e/0x450 Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.5.0-rc3-amd-iommu #6 Hardware name: Lenovo ThinkSystem SR655-2S/7D2WRCZ000, BIOS D8E101L-1.00 12/05/2019 RIP: 0010:flush_workqueue+0x42e/0x450 Code: ff 0f 0b e9 7a fd ff ff 4d 89 ef e9 33 fe ff ff 0f 0b e9 7f fd ff ff 0f 0b e9 bc fd ff ff 0f 0b e9 a8 fd ff ff e8 52 2c fe ff <0f> 0b 31 d2 48 c7 c6 e0 88 c5 95 48 c7 c7 d8 ad f0 95 e8 19 f5 04 RSP: 0000:ffffffff96203d80 EFLAGS: 00010246 RAX: ffffffff96203dc8 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffffffff96a63120 RSI: ffffffff95efcba2 RDI: ffffffff96203dc0 RBP: ffffffff96203e08 R08: 0000000000000000 R09: ffffffff962a1828 R10: 00000000f0000080 R11: dead000000000100 R12: ffff8d8a87c0a770 R13: dead000000000100 R14: 0000000000000456 R15: ffffffff96203da0 FS: 0000000000000000(0000) GS:ffff8d8dbd000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8d91cfbff000 CR3: 000000078920a000 CR4: 00000000000406b0 Call Trace: ? wait_for_completion+0x51/0x180 kmem_cache_destroy+0x69/0x260 iommu_go_to_state+0x40c/0x5ab amd_iommu_prepare+0x16/0x2a irq_remapping_prepare+0x36/0x5f enable_IR_x2apic+0x21/0x172 default_setup_apic_routing+0x12/0x6f apic_intr_mode_init+0x1a1/0x1f1 x86_late_time_init+0x17/0x1c start_kernel+0x480/0x53f secondary_startup_64+0xb6/0xc0 ---[ end trace 30894107c3749449 ]--- x2apic: IRQ remapping doesn't support X2APIC mode x2apic disabled The warning is caused by the calling of 'kmem_cache_destroy()' in free_iommu_resources(). Here is the call path: free_iommu_resources kmem_cache_destroy flush_memcg_workqueue flush_workqueue The root cause is that the IOMMU subsystem runs before the workqueue subsystem, which the variable 'wq_online' is still 'false'. This leads to the statement 'if (WARN_ON(!wq_online))' in flush_workqueue() is 'true'. Since the variable 'memcg_kmem_cache_wq' is not allocated during the time, it is unnecessary to call flush_memcg_workqueue(). This prevents the WARNING message triggered by flush_workqueue(). Link: http://lkml.kernel.org/r/20200103085503.1665-1-ahuang12@lenovo.com Fixes: 92ee383f6daab ("mm: fix race between kmem_cache destroy, create and deactivate") Signed-off-by: Adrian Huang <ahuang12(a)lenovo.com> Reported-by: Xiaochun Lee <lixc17(a)lenovo.com> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: Joerg Roedel <jroedel(a)suse.de> Cc: Christoph Lameter <cl(a)linux.com> Cc: Pekka Enberg <penberg(a)kernel.org> Cc: David Rientjes <rientjes(a)google.com> Cc: Joonsoo Kim <iamjoonsoo.kim(a)lge.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/slab_common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/mm/slab_common.c~mm-memcg-slab-call-flush_memcg_workqueue-only-if-memcg-workqueue-is-valid +++ a/mm/slab_common.c @@ -903,7 +903,8 @@ static void flush_memcg_workqueue(struct * deactivates the memcg kmem_caches through workqueue. Make sure all * previous workitems on workqueue are processed. */ - flush_workqueue(memcg_kmem_cache_wq); + if (likely(memcg_kmem_cache_wq)) + flush_workqueue(memcg_kmem_cache_wq); /* * If we're racing with children kmem_cache deactivation, it might _ Patches currently in -mm which might be from ahuang12(a)lenovo.com are mm-memcg-slab-call-flush_memcg_workqueue-only-if-memcg-workqueue-is-valid.patch

5 years, 10 months

1
0
0 0

stable-rc/linux-4.4.y boot: 46 boots: 0 failed, 45 passed with 1 untried/unknown (v4.4.207-160-gd71a25a44549)

by kernelci.org bot

stable-rc/linux-4.4.y boot: 46 boots: 0 failed, 45 passed with 1 untried/unknown (v4.4.207-160-gd71a25a44549) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.207-160… Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.207-160-gd71a25a44549 Git Commit: d71a25a4454908ef8d0a2851e003e180ca1cd9e7 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 24 unique boards, 9 SoC families, 9 builds out of 190 Boot Regressions Detected: arm: omap2plus_defconfig: gcc-8: am335x-boneblack: lab-baylibre: new failure (last pass: v4.4.207-138-g8eb04883f217) --- For more info write to <info(a)kernelci.org>

5 years, 10 months

1
0
0 0

stable-rc/linux-4.9.y boot: 28 boots: 0 failed, 27 passed with 1 untried/unknown (v4.9.207-207-g455c61b76ca6)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 28 boots: 0 failed, 27 passed with 1 untried/unknown (v4.9.207-207-g455c61b76ca6) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.207-207… Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.207-207-g455c61b76ca6 Git Commit: 455c61b76ca6a510e7f539a6bf611d20116115bd Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 22 unique boards, 9 SoC families, 9 builds out of 183 Boot Regressions Detected: arm: davinci_all_defconfig: gcc-8: da850-lcdk: lab-baylibre: new failure (last pass: v4.9.207-171-g9142f346a4e1) --- For more info write to <info(a)kernelci.org>

5 years, 10 months

1
0
0 0

[PATCH v12 10/22] media/v4l2-core: set pages dirty upon releasing DMA buffers

by John Hubbard

After DMA is complete, and the device and CPU caches are synchronized, it's still required to mark the CPU pages as dirty, if the data was coming from the device. However, this driver was just issuing a bare put_page() call, without any set_page_dirty*() call. Fix the problem, by calling set_page_dirty_lock() if the CPU pages were potentially receiving data from the device. Reviewed-by: Christoph Hellwig <hch(a)lst.de> Acked-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: John Hubbard <jhubbard(a)nvidia.com> --- drivers/media/v4l2-core/videobuf-dma-sg.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c b/drivers/media/v4l2-core/videobuf-dma-sg.c index 66a6c6c236a7..28262190c3ab 100644 --- a/drivers/media/v4l2-core/videobuf-dma-sg.c +++ b/drivers/media/v4l2-core/videobuf-dma-sg.c @@ -349,8 +349,11 @@ int videobuf_dma_free(struct videobuf_dmabuf *dma) BUG_ON(dma->sglen); if (dma->pages) { - for (i = 0; i < dma->nr_pages; i++) + for (i = 0; i < dma->nr_pages; i++) { + if (dma->direction == DMA_FROM_DEVICE) + set_page_dirty_lock(dma->pages[i]); put_page(dma->pages[i]); + } kfree(dma->pages); dma->pages = NULL; } -- 2.24.1

5 years, 10 months

1
0
0 0

stable-rc/linux-4.19.y boot: 54 boots: 2 failed, 50 passed with 2 untried/unknown (v4.19.92-198-gec409c0577a7)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 54 boots: 2 failed, 50 passed with 2 untried/unknown (v4.19.92-198-gec409c0577a7) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.92-19… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.92-198-gec409c0577a7 Git Commit: ec409c0577a786efac650be33aeb59fea89cb950 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 43 unique boards, 13 SoC families, 12 builds out of 202 Boot Regressions Detected: arm64: defconfig: gcc-8: bcm2837-rpi-3-b: lab-baylibre: new failure (last pass: v4.19.92-113-g2686842f2160) meson-gxl-s905d-p230: lab-baylibre: new failure (last pass: v4.19.92-113-g2686842f2160) meson-gxl-s905x-khadas-vim: lab-baylibre: new failure (last pass: v4.19.92-113-g2686842f2160) Boot Failures Detected: arm64: defconfig: gcc-8: bcm2837-rpi-3-b: 1 failed lab meson-gxl-s905x-khadas-vim: 1 failed lab --- For more info write to <info(a)kernelci.org>

5 years, 10 months

1
0
0 0

[PATCH 4.14 0/2] Backport readdir sanity checking patches

by Siddharth Chandrasekaran

Hello, This patchset is a backport of upstream commits that makes getdents() and getdents64() do sanity checking on the pathname that it gives to user space. Sid Linus Torvalds (2): Make filldir[64]() verify the directory entry filename is valid filldir[64]: remove WARN_ON_ONCE() for bad directory entries fs/readdir.c | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) -- 2.7.4

5 years, 10 months

3
13
0 0

stable-rc/linux-4.14.y boot: 47 boots: 2 failed, 43 passed with 2 untried/unknown (v4.14.161-141-ga62afa8ee549)

by kernelci.org bot

stable-rc/linux-4.14.y boot: 47 boots: 2 failed, 43 passed with 2 untried/unknown (v4.14.161-141-ga62afa8ee549) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.161-1… Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.161-141-ga62afa8ee549 Git Commit: a62afa8ee549b0e4824794a5ce23fba7926fb199 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 36 unique boards, 12 SoC families, 11 builds out of 201 Boot Regressions Detected: arm64: defconfig: gcc-8: meson-gxbb-p200: lab-baylibre: new failure (last pass: v4.14.161-90-g01b3c9bf3424) sun50i-a64-bananapi-m64: lab-clabbe: new failure (last pass: v4.14.160) Boot Failures Detected: arm64: defconfig: gcc-8: meson-gxbb-p200: 1 failed lab meson-gxm-q200: 1 failed lab --- For more info write to <info(a)kernelci.org>

5 years, 10 months

1
0
0 0

[PATCH 20/20] tools lib: Fix builds when glibc contains strlcpy()

by Arnaldo Carvalho de Melo

From: Vitaly Chikunov <vt(a)altlinux.org> Disable a couple of compilation warnings (which are treated as errors) on strlcpy() definition and declaration, allowing users to compile perf and kernel (objtool) when: 1. glibc have strlcpy() (such as in ALT Linux since 2004) objtool and perf build fails with this (in gcc): In file included from exec-cmd.c:3: tools/include/linux/string.h:20:15: error: redundant redeclaration of ‘strlcpy’ [-Werror=redundant-decls] 20 | extern size_t strlcpy(char *dest, const char *src, size_t size); 2. clang ignores `-Wredundant-decls', but produces another warning when building perf: CC util/string.o ../lib/string.c:99:8: error: attribute declaration must precede definition [-Werror,-Wignored-attributes] size_t __weak strlcpy(char *dest, const char *src, size_t size) ../../tools/include/linux/compiler.h:66:34: note: expanded from macro '__weak' # define __weak __attribute__((weak)) /usr/include/bits/string_fortified.h:151:8: note: previous definition is here __NTH (strlcpy (char *__restrict __dest, const char *__restrict __src, Committer notes: The #pragma GCC diagnostic directive was introduced in gcc 4.6, so check for that as well. Fixes: ce99091 ("perf tools: Move strlcpy() from perf to tools/lib/string.c") Fixes: 0215d59 ("tools lib: Reinstate strlcpy() header guard with __UCLIBC__") Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=118481 Signed-off-by: Vitaly Chikunov <vt(a)altlinux.org> Reviewed-by: Dmitry Levin <ldv(a)altlinux.org> Cc: Dmitry Levin <ldv(a)altlinux.org> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: kbuild test robot <lkp(a)intel.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: stable(a)vger.kernel.org Cc: Vineet Gupta <vineet.gupta1(a)synopsys.com> Link: http://lore.kernel.org/lkml/20191224172029.19690-1-vt@altlinux.org Signed-off-by: Arnaldo Carvalho de Melo <acme(a)redhat.com> --- tools/include/linux/string.h | 8 ++++++++ tools/lib/string.c | 7 +++++++ 2 files changed, 15 insertions(+) diff --git a/tools/include/linux/string.h b/tools/include/linux/string.h index 980cb9266718..5e9e781905ed 100644 --- a/tools/include/linux/string.h +++ b/tools/include/linux/string.h @@ -17,7 +17,15 @@ int strtobool(const char *s, bool *res); * However uClibc headers also define __GLIBC__ hence the hack below */ #if defined(__GLIBC__) && !defined(__UCLIBC__) +// pragma diagnostic was introduced in gcc 4.6 +#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6) +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored "-Wredundant-decls" +#endif extern size_t strlcpy(char *dest, const char *src, size_t size); +#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 6) +#pragma GCC diagnostic pop +#endif #endif char *str_error_r(int errnum, char *buf, size_t buflen); diff --git a/tools/lib/string.c b/tools/lib/string.c index f2ae1b87c719..f645343815de 100644 --- a/tools/lib/string.c +++ b/tools/lib/string.c @@ -96,6 +96,10 @@ int strtobool(const char *s, bool *res) * If libc has strlcpy() then that version will override this * implementation: */ +#ifdef __clang__ +#pragma clang diagnostic push +#pragma clang diagnostic ignored "-Wignored-attributes" +#endif size_t __weak strlcpy(char *dest, const char *src, size_t size) { size_t ret = strlen(src); @@ -107,6 +111,9 @@ size_t __weak strlcpy(char *dest, const char *src, size_t size) } return ret; } +#ifdef __clang__ +#pragma clang diagnostic pop +#endif /** * skip_spaces - Removes leading whitespace from @str. -- 2.21.1

5 years, 10 months

3
2
0 0

[PATCH backport 4.9 4.4] xhci: fix USB3 device initiated resume race with roothub autosuspend

by Mathias Nyman

commit 057d476fff778f1d3b9f861fdb5437ea1a3cfc99 upstream Backport for 4.9 and 4.4 stable kernels A race in xhci USB3 remote wake handling may force device back to suspend after it initiated resume siganaling, causing a missed resume event or warm reset of device. When a USB3 link completes resume signaling and goes to enabled (UO) state a interrupt is issued and the interrupt handler will clear the bus_state->port_remote_wakeup resume flag, allowing bus suspend. If the USB3 roothub thread just finished reading port status before the interrupt, finding ports still in suspended (U3) state, but hasn't yet started suspending the hub, then the xhci interrupt handler will clear the flag that prevented roothub suspend and allow bus to suspend, forcing all port links back to suspended (U3) state. Example case: usb_runtime_suspend() # because all ports still show suspended U3 usb_suspend_both() hub_suspend(); # successful as hub->wakeup_bits not set yet ==> INTERRUPT xhci_irq() handle_port_status() clear bus_state->port_remote_wakeup usb_wakeup_notification() sets hub->wakeup_bits; kick_hub_wq() <== END INTERRUPT hcd_bus_suspend() xhci_bus_suspend() # success as port_remote_wakeup bits cleared Fix this by increasing roothub usage count during port resume to prevent roothub autosuspend, and by making sure bus_state->port_remote_wakeup flag is only cleared after resume completion is visible, i.e. after xhci roothub returned U0 or other non-U3 link state link on a get port status request. Issue rootcaused by Chiasheng Lee Cc: Lee Hou-hsun <hou-hsun.lee(a)intel.com> Cc: Lee Chiasheng <chiasheng.lee(a)intel.com> Reported-by: Lee Chiasheng <chiasheng.lee(a)intel.com> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> --- drivers/usb/host/xhci-hub.c | 8 ++++++++ drivers/usb/host/xhci-ring.c | 6 +----- drivers/usb/host/xhci.h | 1 + 3 files changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c index 39e2d3271035..1d9cb29400f3 100644 --- a/drivers/usb/host/xhci-hub.c +++ b/drivers/usb/host/xhci-hub.c @@ -760,6 +760,14 @@ static u32 xhci_get_port_status(struct usb_hcd *hcd, status |= USB_PORT_STAT_C_BH_RESET << 16; if ((raw_port_status & PORT_CEC)) status |= USB_PORT_STAT_C_CONFIG_ERROR << 16; + + /* USB3 remote wake resume signaling completed */ + if (bus_state->port_remote_wakeup & (1 << wIndex) && + (raw_port_status & PORT_PLS_MASK) != XDEV_RESUME && + (raw_port_status & PORT_PLS_MASK) != XDEV_RECOVERY) { + bus_state->port_remote_wakeup &= ~(1 << wIndex); + usb_hcd_end_port_resume(&hcd->self, wIndex); + } } if (hcd->speed < HCD_USB3) { diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index 69ad9817076a..b426c83ecb9b 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -1609,9 +1609,6 @@ static void handle_port_status(struct xhci_hcd *xhci, usb_hcd_resume_root_hub(hcd); } - if (hcd->speed >= HCD_USB3 && (temp & PORT_PLS_MASK) == XDEV_INACTIVE) - bus_state->port_remote_wakeup &= ~(1 << faked_port_index); - if ((temp & PORT_PLC) && (temp & PORT_PLS_MASK) == XDEV_RESUME) { xhci_dbg(xhci, "port resume event for port %d\n", port_id); @@ -1630,6 +1627,7 @@ static void handle_port_status(struct xhci_hcd *xhci, bus_state->port_remote_wakeup |= 1 << faked_port_index; xhci_test_and_clear_bit(xhci, port_array, faked_port_index, PORT_PLC); + usb_hcd_start_port_resume(&hcd->self, faked_port_index); xhci_set_link_state(xhci, port_array, faked_port_index, XDEV_U0); /* Need to wait until the next link state change @@ -1667,8 +1665,6 @@ static void handle_port_status(struct xhci_hcd *xhci, if (slot_id && xhci->devs[slot_id]) xhci_ring_device(xhci, slot_id); if (bus_state->port_remote_wakeup & (1 << faked_port_index)) { - bus_state->port_remote_wakeup &= - ~(1 << faked_port_index); xhci_test_and_clear_bit(xhci, port_array, faked_port_index, PORT_PLC); usb_wakeup_notification(hcd->self.root_hub, diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h index de4771ce0df6..424c07d1ac0e 100644 --- a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@ -316,6 +316,7 @@ struct xhci_op_regs { #define XDEV_U3 (0x3 << 5) #define XDEV_INACTIVE (0x6 << 5) #define XDEV_POLLING (0x7 << 5) +#define XDEV_RECOVERY (0x8 << 5) #define XDEV_COMP_MODE (0xa << 5) #define XDEV_RESUME (0xf << 5) /* true: port has power (see HCC_PPC) */ -- 2.17.1

5 years, 10 months

3
2
0 0

Please backport "mwifiex: Fix NL80211_TX_POWER_LIMITED" to stable branches

by Adrian Bunk

Please backport commit 65a576e27309120e0621f54d5c81eb9128bd56be "mwifiex: Fix NL80211_TX_POWER_LIMITED" to stable branches. It is a non-CVE kind of security issue when a wifi adapter exceeds the configured TX power limit. The commit applies and builds against all branches from 3.16 to 4.19, confirmed working with 4.14. It is already included in kernel 5.3. Thanks in advance Adrian

5 years, 10 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror