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

+ mm-ksm-fix-incorrect-ksm-counter-handling-in-mm_struct-during-fork.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: mm/ksm: fix incorrect KSM counter handling in mm_struct during fork has been added to the -mm mm-new branch. Its filename is mm-ksm-fix-incorrect-ksm-counter-handling-in-mm_struct-during-fork.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. 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 via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Donet Tom <donettom(a)linux.ibm.com> Subject: mm/ksm: fix incorrect KSM counter handling in mm_struct during fork Date: Mon, 15 Sep 2025 20:33:04 +0530 Patch series "mm/ksm: Fix incorrect accounting of KSM counters during fork.", v2. The first patch in this series fixes the incorrect accounting of KSM counters such as ksm_merging_pages, ksm_rmap_items, and the global ksm_zero_pages during fork. The following two patches add selftests to verify that the ksm_merging_pages counter and the global ksm_zero_pages counter are updated correctly during fork. Test Results ============ Without the first patch ----------------------- # [RUN] test_fork_ksm_merging_page_count not ok 10 ksm_merging_page in child: 32 # [RUN] test_fork_global_ksm_zero_pages_count not ok 11 Incorrect global ksm zero page counter after fork With the first patch -------------------- # [RUN] test_fork_ksm_merging_page_count ok 10 ksm_merging_pages is not inherited after fork # [RUN] test_fork_global_ksm_zero_pages_count ok 11 Global ksm zero page count is correct after fork This patch (of 3): Currently, the KSM-related counters in `mm_struct`, such as `ksm_merging_pages`, `ksm_rmap_items`, and `ksm_zero_pages`, are inherited by the child process during fork. This results in inconsistent accounting. When a process uses KSM, identical pages are merged and an rmap item is created for each merged page. The `ksm_merging_pages` and `ksm_rmap_items` counters are updated accordingly. However, after a fork, these counters are copied to the child while the corresponding rmap items are not. As a result, when the child later triggers an unmerge, there are no rmap items present in the child, so the counters remain stale, leading to incorrect accounting. A similar issue exists with `ksm_zero_pages`, which maintains both a global counter and a per-process counter. During fork, the per-process counter is inherited by the child, but the global counter is not incremented. Since the child also references zero pages, the global counter should be updated as well. Otherwise, during zero-page unmerge, both the global and per-process counters are decremented, causing the global counter to become inconsistent. To fix this, ksm_merging_pages and ksm_rmap_items are reset to 0 during fork, and the global ksm_zero_pages counter is updated with the per-process ksm_zero_pages value inherited by the child. This ensures that KSM statistics remain accurate and reflect the activity of each process correctly. Link: https://lkml.kernel.org/r/cover.1757946863.git.donettom@linux.ibm.com Link: https://lkml.kernel.org/r/4044e7623953d9f4c240d0308cf0b2fe769ee553.17579468… Fixes: 7609385337a4 ("ksm: count ksm merging pages for each process") Fixes: cb4df4cae4f2 ("ksm: count allocated ksm rmap_items for each process") Fixes: e2942062e01d ("ksm: count all zero pages placed by KSM") Signed-off-by: Donet Tom <donettom(a)linux.ibm.com> Cc: Aboorva Devarajan <aboorvad(a)linux.ibm.com> Cc: Chengming Zhou <chengming.zhou(a)linux.dev> Cc: David Hildenbrand <david(a)redhat.com> Cc: "Ritesh Harjani (IBM)" <ritesh.list(a)gmail.com> Cc: Wei Yang <richard.weiyang(a)gmail.com> Cc: xu xin <xu.xin16(a)zte.com.cn> Cc: <stable(a)vger.kernel.org> [6.6] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/ksm.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/include/linux/ksm.h~mm-ksm-fix-incorrect-ksm-counter-handling-in-mm_struct-during-fork +++ a/include/linux/ksm.h @@ -56,8 +56,14 @@ static inline long mm_ksm_zero_pages(str static inline void ksm_fork(struct mm_struct *mm, struct mm_struct *oldmm) { /* Adding mm to ksm is best effort on fork. */ - if (mm_flags_test(MMF_VM_MERGEABLE, oldmm)) + if (mm_flags_test(MMF_VM_MERGEABLE, oldmm)) { + long nr_ksm_zero_pages = atomic_long_read(&mm->ksm_zero_pages); + + mm->ksm_merging_pages = 0; + mm->ksm_rmap_items = 0; + atomic_long_add(nr_ksm_zero_pages, &ksm_zero_pages); __ksm_enter(mm); + } } static inline int ksm_execve(struct mm_struct *mm) _ Patches currently in -mm which might be from donettom(a)linux.ibm.com are mm-ksm-fix-incorrect-ksm-counter-handling-in-mm_struct-during-fork.patch selftests-mm-added-fork-inheritance-test-for-ksm_merging_pages-counter.patch selftests-mm-added-fork-test-to-verify-global-ksm_zero_pages-counter-behavior.patch

12 hours, 20 minutes

1
0
0 0

[regression] 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY") causes issue with ID 4c4a:4155 Jieli Technology USB Composite Device

by Salvatore Bonaccorso

Hi Zhang, hi Jiri, In Debian Staffan Melin reported that after an update containing the commit 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY"), the input device with same idVendor and idProduct, the Jieli Technology USB Composite Device, does not get recognized anymore. The full Debian report is at: https://bugs.debian.org/1114557 The issue is not specific to the 6.12.y series and confirmed in 6.16.3 as well. Staffan Melin did bisect the kernels between 6.12.38 (which was still working) and 6.1.41 (which was not), confirming by bisection that the offending commit is 1a8953f4f774 ("HID: Add IGNORE quirk for SMARTLINKTECHNOLOGY") #regzbot introduced: 1a8953f4f774 #regzbot monitor: https://bugs.debian.org/1114557 So it looks that the quirk applied is unfortunately affecting negatively as well Staffan Melin case. Can you have a look? Regards, Salvatore

12 hours, 58 minutes

4
9
0 0

[PATCH] binder: fix double-free in dbitmap

by Carlos Llamas

A process might fail to allocate a new bitmap when trying to expand its proc->dmap. In that case, dbitmap_grow() fails and frees the old bitmap via dbitmap_free(). However, the driver calls dbitmap_free() again when the same process terminates, leading to a double-free error: ================================================================== BUG: KASAN: double-free in binder_proc_dec_tmpref+0x2e0/0x55c Free of addr ffff00000b7c1420 by task kworker/9:1/209 CPU: 9 UID: 0 PID: 209 Comm: kworker/9:1 Not tainted 6.17.0-rc6-dirty #5 PREEMPT Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: kfree+0x164/0x31c binder_proc_dec_tmpref+0x2e0/0x55c binder_deferred_func+0xc24/0x1120 process_one_work+0x520/0xba4 [...] Allocated by task 448: __kmalloc_noprof+0x178/0x3c0 bitmap_zalloc+0x24/0x30 binder_open+0x14c/0xc10 [...] Freed by task 449: kfree+0x184/0x31c binder_inc_ref_for_node+0xb44/0xe44 binder_transaction+0x29b4/0x7fbc binder_thread_write+0x1708/0x442c binder_ioctl+0x1b50/0x2900 [...] ================================================================== Fix this issue by marking proc->map NULL in dbitmap_free(). Cc: stable(a)vger.kernel.org Fixes: 15d9da3f818c ("binder: use bitmap for faster descriptor lookup") Signed-off-by: Carlos Llamas <cmllamas(a)google.com> --- drivers/android/dbitmap.h | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/android/dbitmap.h b/drivers/android/dbitmap.h index 956f1bd087d1..c7299ce8b374 100644 --- a/drivers/android/dbitmap.h +++ b/drivers/android/dbitmap.h @@ -37,6 +37,7 @@ static inline void dbitmap_free(struct dbitmap *dmap) { dmap->nbits = 0; kfree(dmap->map); + dmap->map = NULL; } /* Returns the nbits that a dbitmap can shrink to, 0 if not possible. */ -- 2.51.0.384.g4c02a37b29-goog

13 hours, 14 minutes

2
1
0 0

+ mm-fix-off-by-one-error-in-vma-count-limit-checks.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: fix off-by-one error in VMA count limit checks has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-fix-off-by-one-error-in-vma-count-limit-checks.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm 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 via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Kalesh Singh <kaleshsingh(a)google.com> Subject: mm: fix off-by-one error in VMA count limit checks Date: Mon, 15 Sep 2025 09:36:32 -0700 The VMA count limit check in do_mmap() and do_brk_flags() uses a strict inequality (>), which allows a process's VMA count to exceed the configured sysctl_max_map_count limit by one. A process with mm->map_count == sysctl_max_map_count will incorrectly pass this check and then exceed the limit upon allocation of a new VMA when its map_count is incremented. Other VMA allocation paths, such as split_vma(), already use the correct, inclusive (>=) comparison. Fix this bug by changing the comparison to be inclusive in do_mmap() and do_brk_flags(), bringing them in line with the correct behavior of other allocation paths. Link: https://lkml.kernel.org/r/20250915163838.631445-2-kaleshsingh@google.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kalesh Singh <kaleshsingh(a)google.com> Cc: David Hildenbrand <david(a)redhat.com> Cc: "Liam R. Howlett" <Liam.Howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Pedro Falcato <pfalcato(a)suse.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/mmap.c | 2 +- mm/vma.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) --- a/mm/mmap.c~mm-fix-off-by-one-error-in-vma-count-limit-checks +++ a/mm/mmap.c @@ -374,7 +374,7 @@ unsigned long do_mmap(struct file *file, return -EOVERFLOW; /* Too many mappings? */ - if (mm->map_count > sysctl_max_map_count) + if (mm->map_count >= sysctl_max_map_count) return -ENOMEM; /* --- a/mm/vma.c~mm-fix-off-by-one-error-in-vma-count-limit-checks +++ a/mm/vma.c @@ -2772,7 +2772,7 @@ int do_brk_flags(struct vma_iterator *vm if (!may_expand_vm(mm, vm_flags, len >> PAGE_SHIFT)) return -ENOMEM; - if (mm->map_count > sysctl_max_map_count) + if (mm->map_count >= sysctl_max_map_count) return -ENOMEM; if (security_vm_enough_memory_mm(mm, len >> PAGE_SHIFT)) _ Patches currently in -mm which might be from kaleshsingh(a)google.com are mm-fix-off-by-one-error-in-vma-count-limit-checks.patch

13 hours, 28 minutes

1
0
0 0

[PATCH 2/2] slab: mark slab->obj_exts allocation failures unconditionally

by Suren Baghdasaryan

alloc_slab_obj_exts() should mark failed obj_exts vector allocations independent on whether the vector is being allocated for a new or an existing slab. Current implementation skips doing this for existing slabs. Fix this by marking failed allocations unconditionally. Fixes: 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations") Reported-by: Shakeel Butt <shakeel.butt(a)linux.dev> Closes: https://lore.kernel.org/all/avhakjldsgczmq356gkwmvfilyvf7o6temvcmtt5lqd4fhp… Signed-off-by: Suren Baghdasaryan <surenb(a)google.com> Cc: stable(a)vger.kernel.org # v6.10+ --- mm/slub.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index af343ca570b5..cab4e7822393 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2029,8 +2029,7 @@ int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s, slab_nid(slab)); if (!vec) { /* Mark vectors which failed to allocate */ - if (new_slab) - mark_failed_objexts_alloc(slab); + mark_failed_objexts_alloc(slab); return -ENOMEM; } -- 2.51.0.384.g4c02a37b29-goog

15 hours, 50 minutes

2
1
0 0

[PATCH 1/2] slab: prevent warnings when slab obj_exts vector allocation fails

by Suren Baghdasaryan

When object extension vector allocation fails, we set slab->obj_exts to OBJEXTS_ALLOC_FAIL to indicate the failure. Later, once the vector is successfully allocated, we will use this flag to mark codetag references stored in that vector as empty to avoid codetag warnings. slab_obj_exts() used to retrieve the slab->obj_exts vector pointer checks slab->obj_exts for being either NULL or a pointer with MEMCG_DATA_OBJEXTS bit set. However it does not handle the case when slab->obj_exts equals OBJEXTS_ALLOC_FAIL. Add the missing condition to avoid extra warning. Fixes: 09c46563ff6d ("codetag: debug: introduce OBJEXTS_ALLOC_FAIL to mark failed slab_ext allocations") Reported-by: Shakeel Butt <shakeel.butt(a)linux.dev> Closes: https://lore.kernel.org/all/jftidhymri2af5u3xtcqry3cfu6aqzte3uzlznhlaylgrdz… Signed-off-by: Suren Baghdasaryan <surenb(a)google.com> Cc: stable(a)vger.kernel.org # v6.10+ --- mm/slab.h | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/mm/slab.h b/mm/slab.h index c41a512dd07c..b930193fd94e 100644 --- a/mm/slab.h +++ b/mm/slab.h @@ -526,8 +526,12 @@ static inline struct slabobj_ext *slab_obj_exts(struct slab *slab) unsigned long obj_exts = READ_ONCE(slab->obj_exts); #ifdef CONFIG_MEMCG - VM_BUG_ON_PAGE(obj_exts && !(obj_exts & MEMCG_DATA_OBJEXTS), - slab_page(slab)); + /* + * obj_exts should be either NULL, a valid pointer with + * MEMCG_DATA_OBJEXTS bit set or be equal to OBJEXTS_ALLOC_FAIL. + */ + VM_BUG_ON_PAGE(obj_exts && !(obj_exts & MEMCG_DATA_OBJEXTS) && + obj_exts != OBJEXTS_ALLOC_FAIL, slab_page(slab)); VM_BUG_ON_PAGE(obj_exts & MEMCG_DATA_KMEM, slab_page(slab)); #endif return (struct slabobj_ext *)(obj_exts & ~OBJEXTS_FLAGS_MASK); -- 2.51.0.384.g4c02a37b29-goog

15 hours, 50 minutes

2
1
0 0

[PATCH] io_uring/io-wq: fix `max_workers` breakage and `nr_workers` underflow

by Max Kellermann

Commit 88e6c42e40de ("io_uring/io-wq: add check free worker before create new worker") reused the variable `do_create` for something else, abusing it for the free worker check. This caused the value to effectively always be `true` at the time `nr_workers < max_workers` was checked, but it should really be `false`. This means the `max_workers` setting was ignored, and worse: if the limit had already been reached, incrementing `nr_workers` was skipped even though another worker would be created. When later lots of workers exit, the `nr_workers` field could easily underflow, making the problem worse because more and more workers would be created without incrementing `nr_workers`. The simple solution is to use a different variable for the free worker check instead of using one variable for two different things. Cc: stable(a)vger.kernel.org Fixes: 88e6c42e40de ("io_uring/io-wq: add check free worker before create new worker") Signed-off-by: Max Kellermann <max.kellermann(a)ionos.com> --- io_uring/io-wq.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/io_uring/io-wq.c b/io_uring/io-wq.c index 17dfaa0395c4..1d03b2fc4b25 100644 --- a/io_uring/io-wq.c +++ b/io_uring/io-wq.c @@ -352,16 +352,16 @@ static void create_worker_cb(struct callback_head *cb) struct io_wq *wq; struct io_wq_acct *acct; - bool do_create = false; + bool activated_free_worker, do_create = false; worker = container_of(cb, struct io_worker, create_work); wq = worker->wq; acct = worker->acct; rcu_read_lock(); - do_create = !io_acct_activate_free_worker(acct); + activated_free_worker = io_acct_activate_free_worker(acct); rcu_read_unlock(); - if (!do_create) + if (activated_free_worker) goto no_need_create; raw_spin_lock(&acct->workers_lock); -- 2.47.3

16 hours, 59 minutes

3
2
0 0

Re: [linux-next20250911]Kernel OOPs while running generic/256 on Pmem device

by Venkat

> On 12 Sep 2025, at 10:51 AM, Venkat Rao Bagalkote <venkat88(a)linux.ibm.com> wrote: > > Greetings!!! > > > IBM CI has reported a kernel crash, while running generic/256 test case on pmem device from xfstests suite on linux-next20250911 kernel. > > > xfstests: git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git > > local.config: > > [xfs_dax] > export RECREATE_TEST_DEV=true > export TEST_DEV=/dev/pmem0 > export TEST_DIR=/mnt/test_pmem > export SCRATCH_DEV=/dev/pmem0.1 > export SCRATCH_MNT=/mnt/scratch_pmem > export MKFS_OPTIONS="-m reflink=0 -b size=65536 -s size=512" > export FSTYP=xfs > export MOUNT_OPTIONS="-o dax" > > > Test case: generic/256 > > > Traces: > > > [ 163.371929] ------------[ cut here ]------------ > [ 163.371936] kernel BUG at lib/list_debug.c:29! > [ 163.371946] Oops: Exception in kernel mode, sig: 5 [#1] > [ 163.371954] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=8192 NUMA pSeries > [ 163.371965] Modules linked in: xfs nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack bonding tls nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set nf_tables nfnetlink sunrpc pseries_rng vmx_crypto dax_pmem fuse ext4 crc16 mbcache jbd2 nd_pmem papr_scm sd_mod libnvdimm sg ibmvscsi ibmveth scsi_transport_srp pseries_wdt > [ 163.372127] CPU: 22 UID: 0 PID: 130 Comm: kworker/22:0 Kdump: loaded Not tainted 6.17.0-rc5-next-20250911 #1 VOLUNTARY > [ 163.372142] Hardware name: IBM,9080-HEX Power11 (architected) 0x820200 0xf000007 of:IBM,FW1110.01 (NH1110_069) hv:phyp pSeries > [ 163.372155] Workqueue: cgroup_free css_free_rwork_fn > [ 163.372169] NIP: c000000000d051d4 LR: c000000000d051d0 CTR: 0000000000000000 > [ 163.372176] REGS: c00000000ba079b0 TRAP: 0700 Not tainted (6.17.0-rc5-next-20250911) > [ 163.372183] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28000000 XER: 00000006 > [ 163.372214] CFAR: c0000000002bae9c IRQMASK: 0 > [ 163.372214] GPR00: c000000000d051d0 c00000000ba07c50 c00000000230a600 0000000000000075 > [ 163.372214] GPR04: 0000000000000004 0000000000000001 c000000000507e2c 0000000000000001 > [ 163.372214] GPR08: c000000d0cb87d13 0000000000000000 0000000000000000 a80e000000000000 > [ 163.372214] GPR12: c00e0001a1970fa2 c000000d0ddec700 c000000000208e58 c000000107b5e190 > [ 163.372214] GPR16: c00000000d3e5d08 c00000000b71cf78 c00000000d3e5d05 c00000000b71cf30 > [ 163.372214] GPR20: c00000000b71cf08 c00000000b71cf10 c000000019f58588 c000000004704bc8 > [ 163.372214] GPR24: c000000107b5e100 c000000004704bd0 0000000000000003 c000000004704bd0 > [ 163.372214] GPR28: c000000004704bc8 c000000019f585a8 c000000019f53da8 c000000004704bc8 > [ 163.372315] NIP [c000000000d051d4] __list_add_valid_or_report+0x124/0x188 > [ 163.372326] LR [c000000000d051d0] __list_add_valid_or_report+0x120/0x188 > [ 163.372335] Call Trace: > [ 163.372339] [c00000000ba07c50] [c000000000d051d0] __list_add_valid_or_report+0x120/0x188 (unreliable) > [ 163.372352] [c00000000ba07ce0] [c000000000834280] mem_cgroup_css_free+0xa0/0x27c > [ 163.372363] [c00000000ba07d50] [c0000000003ba198] css_free_rwork_fn+0xd0/0x59c > [ 163.372374] [c00000000ba07da0] [c0000000001f5d60] process_one_work+0x41c/0x89c > [ 163.372385] [c00000000ba07eb0] [c0000000001f76c0] worker_thread+0x558/0x848 > [ 163.372394] [c00000000ba07f80] [c000000000209038] kthread+0x1e8/0x230 > [ 163.372406] [c00000000ba07fe0] [c00000000000ded8] start_kernel_thread+0x14/0x18 > [ 163.372416] Code: 4b9b1099 60000000 7f63db78 4bae8245 60000000 e8bf0008 3c62ff88 7fe6fb78 7fc4f378 38637d40 4b5b5c89 60000000 <0fe00000> 60000000 60000000 7f83e378 > [ 163.372453] ---[ end trace 0000000000000000 ]--- > [ 163.380581] pstore: backend (nvram) writing error (-1) > [ 163.380593] > > > If you happen to fix this issue, please add below tag. > > > Reported-by: Venkat Rao Bagalkote <venkat88(a)linux.ibm.com> > > > > Regards, > > Venkat. > > After reverting the below commit, issue is not seen. commit 61bbf51e75df1a94cf6736e311cb96aeb79826a8 Author: Julian Sun <sunjunchao(a)bytedance.com> Date: Thu Aug 28 04:45:57 2025 +0800 memcg: don't wait writeback completion when release memcg Recently, we encountered the following hung task: INFO: task kworker/4:1:1334558 blocked for more than 1720 seconds. [Wed Jul 30 17:47:45 2025] Workqueue: cgroup_destroy css_free_rwork_fn [Wed Jul 30 17:47:45 2025] Call Trace: [Wed Jul 30 17:47:45 2025] __schedule+0x934/0xe10 [Wed Jul 30 17:47:45 2025] ? complete+0x3b/0x50 [Wed Jul 30 17:47:45 2025] ? _cond_resched+0x15/0x30 [Wed Jul 30 17:47:45 2025] schedule+0x40/0xb0 [Wed Jul 30 17:47:45 2025] wb_wait_for_completion+0x52/0x80 [Wed Jul 30 17:47:45 2025] ? finish_wait+0x80/0x80 [Wed Jul 30 17:47:45 2025] mem_cgroup_css_free+0x22/0x1b0 [Wed Jul 30 17:47:45 2025] css_free_rwork_fn+0x42/0x380 [Wed Jul 30 17:47:45 2025] process_one_work+0x1a2/0x360 [Wed Jul 30 17:47:45 2025] worker_thread+0x30/0x390 [Wed Jul 30 17:47:45 2025] ? create_worker+0x1a0/0x1a0 [Wed Jul 30 17:47:45 2025] kthread+0x110/0x130 [Wed Jul 30 17:47:45 2025] ? __kthread_cancel_work+0x40/0x40 [Wed Jul 30 17:47:45 2025] ret_from_fork+0x1f/0x30 The direct cause is that memcg spends a long time waiting for dirty page writeback of foreign memcgs during release. The root causes are: a. The wb may have multiple writeback tasks, containing millions of dirty pages, as shown below: >>> for work in list_for_each_entry("struct wb_writeback_work", \ wb.work_list.address_of_(), "list"): ... print(work.nr_pages, work.reason, hex(work)) ... 900628 WB_REASON_FOREIGN_FLUSH 0xffff969e8d956b40 1116521 WB_REASON_FOREIGN_FLUSH 0xffff9698332a9540 1275228 WB_REASON_FOREIGN_FLUSH 0xffff969d9b444bc0 1099673 WB_REASON_FOREIGN_FLUSH 0xffff969f0954d6c0 1351522 WB_REASON_FOREIGN_FLUSH 0xffff969e76713340 2567437 WB_REASON_FOREIGN_FLUSH 0xffff9694ae208400 2954033 WB_REASON_FOREIGN_FLUSH 0xffff96a22d62cbc0 3008860 WB_REASON_FOREIGN_FLUSH 0xffff969eee8ce3c0 3337932 WB_REASON_FOREIGN_FLUSH 0xffff9695b45156c0 3348916 WB_REASON_FOREIGN_FLUSH 0xffff96a22c7a4f40 3345363 WB_REASON_FOREIGN_FLUSH 0xffff969e5d872800 3333581 WB_REASON_FOREIGN_FLUSH 0xffff969efd0f4600 3382225 WB_REASON_FOREIGN_FLUSH 0xffff969e770edcc0 3418770 WB_REASON_FOREIGN_FLUSH 0xffff96a252ceea40 3387648 WB_REASON_FOREIGN_FLUSH 0xffff96a3bda86340 3385420 WB_REASON_FOREIGN_FLUSH 0xffff969efc6eb280 3418730 WB_REASON_FOREIGN_FLUSH 0xffff96a348ab1040 3426155 WB_REASON_FOREIGN_FLUSH 0xffff969d90beac00 3397995 WB_REASON_FOREIGN_FLUSH 0xffff96a2d7288800 3293095 WB_REASON_FOREIGN_FLUSH 0xffff969dab423240 3293595 WB_REASON_FOREIGN_FLUSH 0xffff969c765ff400 3199511 WB_REASON_FOREIGN_FLUSH 0xffff969a72d5e680 3085016 WB_REASON_FOREIGN_FLUSH 0xffff969f0455e000 3035712 WB_REASON_FOREIGN_FLUSH 0xffff969d9bbf4b00 b. The writeback might severely throttled by wbt, with a speed possibly less than 100kb/s, leading to a very long writeback time. >>> wb.write_bandwidth (unsigned long)24 >>> wb.write_bandwidth (unsigned long)13 The wb_wait_for_completion() here is probably only used to prevent use-after-free. Therefore, we manage 'done' separately and automatically free it. This allows us to remove wb_wait_for_completion() while preventing the use-after-free issue. com Fixes: 97b27821b485 ("writeback, memcg: Implement foreign dirty flushing") Signed-off-by: Julian Sun <sunjunchao(a)bytedance.com> Acked-by: Tejun Heo <tj(a)kernel.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: Muchun Song <songmuchun(a)bytedance.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Regards, Venkat. >

17 hours, 44 minutes

3
6
0 0

[PATCH] irqchip/sifive-plic: avoid interrupt ID 0 handling during suspend/resume

by Lucas Zampieri

To: linux-kernel(a)vger.kernel.org Cc: Paul Walmsley <paul.walmsley(a)sifive.com> Cc: Samuel Holland <samuel.holland(a)sifive.com> Cc: stable(a)vger.kernel.org Cc: linux-riscv(a)lists.infradead.org Cc: Thomas Gleixner <tglx(a)linutronix.de> According to the PLIC specification[1], global interrupt sources are assigned small unsigned integer identifiers beginning at the value 1. An interrupt ID of 0 is reserved to mean "no interrupt". The current plic_irq_resume() and plic_irq_suspend() functions incorrectly starts the loop from index 0, which could access the reserved interrupt ID 0 register space. This fix changes the loop to start from index 1, skipping the reserved interrupt ID 0 as per the PLIC specification. This prevents potential undefined behavior when accessing the reserved register space during suspend/resume cycles. Fixes: e80f0b6a2cf3 ("irqchip/irq-sifive-plic: Add syscore callbacks for hibernation") Co-developed-by: Jia Wang <wangjia(a)ultrarisc.com> Signed-off-by: Jia Wang <wangjia(a)ultrarisc.com> Signed-off-by: Lucas Zampieri <lzampier(a)redhat.com> [1] https://github.com/riscv/riscv-plic-spec/releases/tag/1.0.0 --- drivers/irqchip/irq-sifive-plic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/irqchip/irq-sifive-plic.c b/drivers/irqchip/irq-sifive-plic.c index bf69a4802b71..1c2b4d2575ac 100644 --- a/drivers/irqchip/irq-sifive-plic.c +++ b/drivers/irqchip/irq-sifive-plic.c @@ -252,7 +252,7 @@ static int plic_irq_suspend(void) priv = per_cpu_ptr(&plic_handlers, smp_processor_id())->priv; - for (i = 0; i < priv->nr_irqs; i++) { + for (i = 1; i < priv->nr_irqs; i++) { __assign_bit(i, priv->prio_save, readl(priv->regs + PRIORITY_BASE + i * PRIORITY_PER_ID)); } @@ -283,7 +283,7 @@ static void plic_irq_resume(void) priv = per_cpu_ptr(&plic_handlers, smp_processor_id())->priv; - for (i = 0; i < priv->nr_irqs; i++) { + for (i = 1; i < priv->nr_irqs; i++) { index = BIT_WORD(i); writel((priv->prio_save[index] & BIT_MASK(i)) ? 1 : 0, priv->regs + PRIORITY_BASE + i * PRIORITY_PER_ID); -- 2.51.0

19 hours, 36 minutes

1
0
0 0

[PATCH v3 1/3] vhost-net: unbreak busy polling

by Michael S. Tsirkin

From: Jason Wang <jasowang(a)redhat.com> Commit 67a873df0c41 ("vhost: basic in order support") pass the number of used elem to vhost_net_rx_peek_head_len() to make sure it can signal the used correctly before trying to do busy polling. But it forgets to clear the count, this would cause the count run out of sync with handle_rx() and break the busy polling. Fixing this by passing the pointer of the count and clearing it after the signaling the used. Acked-by: Michael S. Tsirkin <mst(a)redhat.com> Cc: stable(a)vger.kernel.org Fixes: 67a873df0c41 ("vhost: basic in order support") Signed-off-by: Jason Wang <jasowang(a)redhat.com> Message-Id: <20250915024703.2206-1-jasowang(a)redhat.com> Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com> --- drivers/vhost/net.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index c6508fe0d5c8..16e39f3ab956 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -1014,7 +1014,7 @@ static int peek_head_len(struct vhost_net_virtqueue *rvq, struct sock *sk) } static int vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk, - bool *busyloop_intr, unsigned int count) + bool *busyloop_intr, unsigned int *count) { struct vhost_net_virtqueue *rnvq = &net->vqs[VHOST_NET_VQ_RX]; struct vhost_net_virtqueue *tnvq = &net->vqs[VHOST_NET_VQ_TX]; @@ -1024,7 +1024,8 @@ static int vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk, if (!len && rvq->busyloop_timeout) { /* Flush batched heads first */ - vhost_net_signal_used(rnvq, count); + vhost_net_signal_used(rnvq, *count); + *count = 0; /* Both tx vq and rx socket were polled here */ vhost_net_busy_poll(net, rvq, tvq, busyloop_intr, true); @@ -1180,7 +1181,7 @@ static void handle_rx(struct vhost_net *net) do { sock_len = vhost_net_rx_peek_head_len(net, sock->sk, - &busyloop_intr, count); + &busyloop_intr, &count); if (!sock_len) break; sock_len += sock_hlen; -- MST

20 hours, 2 minutes

1
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror