Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mm/mglru: fix lockless folio_putback_lru() race in evict_folios()
@ 2026-08-07 10:30 Ketan Kishore
  2026-08-07 15:12 ` Shakeel Butt
  2026-08-07 17:02 ` [syzbot ci] " syzbot ci
  0 siblings, 2 replies; 3+ messages in thread
From: Ketan Kishore @ 2026-08-07 10:30 UTC (permalink / raw)
  To: Andrew Morton, Johannes Weiner, David Hildenbrand, Michal Hocko,
	Qi Zheng, Shakeel Butt, Lorenzo Stoakes, Kairui Song, Barry Song,
	Axel Rasmussen, Yuanchu Xie, Wei Xu, Yu Zhao
  Cc: kernel, linux-mm, linux-kernel, Prakash Gupta, Ketan Kishore

folio_putback_lru() requires lru_lock to not be held by the caller,
but it internally calls folio_add_lru() -> lruvec_add_folio() ->
lru_gen_add_folio() -> list_add(), which modifies lrugen->folios[]
without acquiring lruvec->lru_lock.

In evict_folios(), lru_lock is dropped before shrink_folio_list() and
the subsequent list_for_each_entry_safe_reverse() loop. When an
unevictable folio is encountered in this lockless section,
folio_putback_lru() is called to return it to lrugen->folios[]. This
races with any concurrent CPU that holds lru_lock and operates on the
same list (e.g. via list_del or list_move), corrupting prev->next.

The corruption is detected later when move_folios_to_lru() re-acquires
lru_lock and calls list_del() on a folio whose list linkage was
corrupted, triggering BUG at lib/list_debug.c:64:

  list_del corruption. prev->next should be fffffffeead4fbc8,
  but was ffffeafeead44188. (prev=fffffffee4fc4c08)
  kernel BUG at lib/list_debug.c:64!
  Call trace:
   __list_del_entry_valid_or_report+0x100/0x14c
   evict_folios+0x145c/0x16dc
   try_to_shrink_lruvec+0x228/0x35c
   shrink_one+0x94/0x158
   shrink_many+0x1c8/0x1f4
   lru_gen_shrink_node+0x94/0x110
   shrink_node+0x468/0x8b4
   balance_pgdat+0x4f0/0x9a0
   kswapd+0x268/0x470

The race window is amplified when unevictable memory is high, causing
folio_putback_lru() to be called many times in the lockless section.

move_folios_to_lru() already handles this correctly: it drops and
re-acquires lru_lock around folio_putback_lru() for unevictable folios.
Apply the same pattern to evict_folios().

Fixes: 359a5e1416ca ("mm: multi-gen LRU: retry folios written back while isolated")
Signed-off-by: Prakash Gupta <prakash.gupta@oss.qualcomm.com>
Signed-off-by: Ketan Kishore <ketan.kishore@oss.qualcomm.com>
---
 mm/vmscan.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 26436059ea39..7c4adba13e4f 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4923,7 +4923,9 @@ static int evict_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
 
 		if (!folio_evictable(folio)) {
 			list_del(&folio->lru);
+			spin_lock_irq(&lruvec->lru_lock);
 			folio_putback_lru(folio);
+			spin_unlock_irq(&lruvec->lru_lock);
 			continue;
 		}
 

---
base-commit: ea2bff00da89d7767d677bb68470130ba96f4928
change-id: 20260807-evict_folios_race-f3b119e0cf97

Best regards,
--  
Ketan Kishore <ketan.kishore@oss.qualcomm.com>



^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] mm/mglru: fix lockless folio_putback_lru() race in evict_folios()
  2026-08-07 10:30 [PATCH] mm/mglru: fix lockless folio_putback_lru() race in evict_folios() Ketan Kishore
@ 2026-08-07 15:12 ` Shakeel Butt
  2026-08-07 17:02 ` [syzbot ci] " syzbot ci
  1 sibling, 0 replies; 3+ messages in thread
From: Shakeel Butt @ 2026-08-07 15:12 UTC (permalink / raw)
  To: Ketan Kishore
  Cc: Andrew Morton, Johannes Weiner, David Hildenbrand, Michal Hocko,
	Qi Zheng, Lorenzo Stoakes, Kairui Song, Barry Song,
	Axel Rasmussen, Yuanchu Xie, Wei Xu, Yu Zhao, kernel, linux-mm,
	linux-kernel, Prakash Gupta

On Fri, Aug 07, 2026 at 04:00:30PM +0530, Ketan Kishore wrote:
> folio_putback_lru() requires lru_lock to not be held by the caller,
> but it internally calls folio_add_lru() -> lruvec_add_folio() ->
> lru_gen_add_folio() -> list_add(), which modifies lrugen->folios[]
> without acquiring lruvec->lru_lock.

folio_putback_lru() requires lru_lock to not be held because it holds lru lock
internally.

folio_putback_lru
  folio_add_lru
    __folio_batch_add_and_move
      folio_batch_move_lru
        folio_lruvec_relock_irqsave
    

> 
> In evict_folios(), lru_lock is dropped before shrink_folio_list() and
> the subsequent list_for_each_entry_safe_reverse() loop. When an
> unevictable folio is encountered in this lockless section,
> folio_putback_lru() is called to return it to lrugen->folios[]. This
> races with any concurrent CPU that holds lru_lock and operates on the
> same list (e.g. via list_del or list_move), corrupting prev->next.
> 
> The corruption is detected later when move_folios_to_lru() re-acquires
> lru_lock and calls list_del() on a folio whose list linkage was
> corrupted, triggering BUG at lib/list_debug.c:64:
> 
>   list_del corruption. prev->next should be fffffffeead4fbc8,
>   but was ffffeafeead44188. (prev=fffffffee4fc4c08)
>   kernel BUG at lib/list_debug.c:64!
>   Call trace:
>    __list_del_entry_valid_or_report+0x100/0x14c
>    evict_folios+0x145c/0x16dc
>    try_to_shrink_lruvec+0x228/0x35c
>    shrink_one+0x94/0x158
>    shrink_many+0x1c8/0x1f4
>    lru_gen_shrink_node+0x94/0x110
>    shrink_node+0x468/0x8b4
>    balance_pgdat+0x4f0/0x9a0
>    kswapd+0x268/0x470
> 
> The race window is amplified when unevictable memory is high, causing
> folio_putback_lru() to be called many times in the lockless section.
> 
> move_folios_to_lru() already handles this correctly: it drops and
> re-acquires lru_lock around folio_putback_lru() for unevictable folios.
> Apply the same pattern to evict_folios().
> 
> Fixes: 359a5e1416ca ("mm: multi-gen LRU: retry folios written back while isolated")
> Signed-off-by: Prakash Gupta <prakash.gupta@oss.qualcomm.com>
> Signed-off-by: Ketan Kishore <ketan.kishore@oss.qualcomm.com>
> ---
>  mm/vmscan.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 26436059ea39..7c4adba13e4f 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -4923,7 +4923,9 @@ static int evict_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
>  
>  		if (!folio_evictable(folio)) {
>  			list_del(&folio->lru);
> +			spin_lock_irq(&lruvec->lru_lock);
>  			folio_putback_lru(folio);
> +			spin_unlock_irq(&lruvec->lru_lock);

This will introduce a deadlock.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [syzbot ci] Re: mm/mglru: fix lockless folio_putback_lru() race in evict_folios()
  2026-08-07 10:30 [PATCH] mm/mglru: fix lockless folio_putback_lru() race in evict_folios() Ketan Kishore
  2026-08-07 15:12 ` Shakeel Butt
@ 2026-08-07 17:02 ` syzbot ci
  1 sibling, 0 replies; 3+ messages in thread
From: syzbot ci @ 2026-08-07 17:02 UTC (permalink / raw)
  To: akpm, axelrasmussen, baohua, david, hannes, kasong, kernel,
	ketan.kishore, linux-kernel, linux-mm, ljs, mhocko, prakash.gupta,
	qi.zheng, shakeel.butt, weixugc, yuanchu, yuzhao
  Cc: syzbot, syzkaller-bugs

syzbot ci has tested the following series

[v1] mm/mglru: fix lockless folio_putback_lru() race in evict_folios()
https://lore.kernel.org/all/20260807-evict_folios_race-v1-1-b167c6b4cfde@oss.qualcomm.com
* [PATCH] mm/mglru: fix lockless folio_putback_lru() race in evict_folios()

and found the following issue:
possible deadlock in __folio_batch_add_and_move

Full report is available here:
https://ci.syzbot.org/series/84ef3e36-11bb-4ace-93cf-a1d457206afc

***

possible deadlock in __folio_batch_add_and_move

tree:      linux-next
URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next
base:      ea2bff00da89d7767d677bb68470130ba96f4928
arch:      amd64
compiler:  Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
config:    https://ci.syzbot.org/builds/fefee38b-873a-46f2-b7ad-f80279b083f8/config
syz repro: https://ci.syzbot.org/findings/9a05a8ec-c7b9-47ec-8888-0383f37b235c/syz_repro

======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
syz.0.17/5796 is trying to acquire lock:
ffff888121033c10 (lock#3){+.+.}-{3:3}, at: local_lock_acquire include/linux/local_lock_internal.h:46 [inline]
ffff888121033c10 (lock#3){+.+.}-{3:3}, at: __folio_batch_add_and_move+0x11a/0xc50 mm/folio.c:220

but task is already holding lock:
ffff888102ab6cb0 (&lruvec->lru_lock){....}-{3:3}, at: spin_lock_irq include/linux/spinlock.h:372 [inline]
ffff888102ab6cb0 (&lruvec->lru_lock){....}-{3:3}, at: evict_folios+0x3cf5/0x4970 mm/vmscan.c:4926

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (&lruvec->lru_lock){....}-{3:3}:
       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:132 [inline]
       _raw_spin_lock_irqsave+0x40/0x60 kernel/locking/spinlock.c:166
       folio_lruvec_lock_irqsave+0x273/0x550 mm/memcontrol.c:1509
       folio_lruvec_relock_irqsave include/linux/memcontrol.h:1567 [inline]
       folio_batch_move_lru+0x6d3/0xa60 mm/folio.c:192
       __folio_batch_add_and_move+0x510/0xc50 mm/folio.c:224
       shmem_alloc_and_add_folio+0xcc2/0xf60 mm/shmem.c:2033
       shmem_get_folio_gfp+0x5da/0x16d0 mm/shmem.c:2527
       shmem_read_folio_gfp+0x8a/0xe0 mm/shmem.c:5964
       drm_gem_get_pages+0x253/0x9c0 drivers/gpu/drm/drm_gem.c:695
       drm_gem_shmem_get_pages_locked+0x22b/0x480 drivers/gpu/drm/drm_gem_shmem_helper.c:242
       drm_gem_shmem_pin_locked+0x251/0x510 drivers/gpu/drm/drm_gem_shmem_helper.c:305
       drm_gem_shmem_vmap_locked+0x487/0x7d0 drivers/gpu/drm/drm_gem_shmem_helper.c:409
       drm_gem_vmap_locked drivers/gpu/drm/drm_gem.c:1421 [inline]
       drm_gem_vmap+0x10a/0x1d0 drivers/gpu/drm/drm_gem.c:1463
       drm_client_buffer_vmap+0x6c/0xb0 drivers/gpu/drm/drm_client.c:356
       drm_fbdev_shmem_driver_fbdev_probe+0x280/0x930 drivers/gpu/drm/drm_fbdev_shmem.c:159
       drm_fb_helper_single_fb_probe drivers/gpu/drm/drm_fb_helper.c:1544 [inline]
       __drm_fb_helper_initial_config_and_unlock+0x148f/0x1b50 drivers/gpu/drm/drm_fb_helper.c:1725
       drm_fbdev_client_hotplug+0x16c/0x230 drivers/gpu/drm/clients/drm_fbdev_client.c:66
       drm_client_register+0x16e/0x200 drivers/gpu/drm/drm_client.c:143
       drm_fbdev_client_setup+0x1a0/0x450 drivers/gpu/drm/clients/drm_fbdev_client.c:168
       drm_client_setup+0x107/0x220 drivers/gpu/drm/clients/drm_client_setup.c:46
       bochs_pci_probe+0xa9a/0xbb0 drivers/gpu/drm/tiny/bochs.c:776
       local_pci_probe drivers/pci/pci-driver.c:354 [inline]
       pci_call_probe drivers/pci/pci-driver.c:416 [inline]
       __pci_device_probe drivers/pci/pci-driver.c:478 [inline]
       pci_device_probe+0x48e/0xd10 drivers/pci/pci-driver.c:512
       call_driver_probe drivers/base/dd.c:-1 [inline]
       really_probe+0x254/0xae0 drivers/base/dd.c:706
       __driver_probe_device+0x1e8/0x360 drivers/base/dd.c:868
       driver_probe_device+0x4f/0x240 drivers/base/dd.c:898
       __driver_attach+0x339/0x600 drivers/base/dd.c:1292
       bus_for_each_dev+0x23b/0x2c0 drivers/base/bus.c:383
       bus_add_driver+0x345/0x670 drivers/base/bus.c:763
       driver_register+0x23a/0x320 drivers/base/driver.c:174
       do_one_initcall+0x250/0x870 init/main.c:1359
       do_initcall_level+0x10a/0x1a0 init/main.c:1421
       do_initcalls+0x59/0xa0 init/main.c:1437
       kernel_init_freeable+0x29d/0x3e0 init/main.c:1672
       kernel_init+0x22/0x1d0 init/main.c:1562
       ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
       ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

-> #0 (lock#3){+.+.}-{3:3}:
       check_prev_add kernel/locking/lockdep.c:3181 [inline]
       check_prevs_add kernel/locking/lockdep.c:3300 [inline]
       validate_chain kernel/locking/lockdep.c:3924 [inline]
       __lock_acquire+0x15ff/0x2e50 kernel/locking/lockdep.c:5254
       lock_acquire+0x115/0x350 kernel/locking/lockdep.c:5908
       local_lock_acquire include/linux/local_lock_internal.h:46 [inline]
       __folio_batch_add_and_move+0x132/0xc50 mm/folio.c:220
       folio_putback_lru+0x18/0xe0 mm/vmscan.c:822
       evict_folios+0x3cfd/0x4970 mm/vmscan.c:4927
       try_to_shrink_lruvec+0xe3b/0x1340 mm/vmscan.c:5081
       lru_gen_shrink_lruvec mm/vmscan.c:5226 [inline]
       shrink_lruvec+0x54f/0x2c40 mm/vmscan.c:5986
       shrink_node_memcgs mm/vmscan.c:6225 [inline]
       shrink_node+0xa9b/0x3e30 mm/vmscan.c:6269
       shrink_zones mm/vmscan.c:6508 [inline]
       do_try_to_free_pages+0x6a3/0x1990 mm/vmscan.c:6570
       try_to_free_mem_cgroup_pages+0x30d/0x830 mm/vmscan.c:6892
       mem_cgroup_resize_max+0x23c/0x470 mm/memcontrol-v1.c:1817
       mem_cgroup_write+0x223/0x290 mm/memcontrol-v1.c:-1
       cgroup_file_write+0x331/0x8f0 kernel/cgroup/cgroup.c:4412
       kernfs_fop_write_iter+0x3a4/0x540 fs/kernfs/file.c:345
       new_sync_write fs/read_write.c:595 [inline]
       vfs_write+0x612/0xba0 fs/read_write.c:687
       ksys_write+0x150/0x270 fs/read_write.c:739
       do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
       do_syscall_64+0x166/0x510 arch/x86/entry/syscall_64.c:84
       entry_SYSCALL_64_after_hwframe+0x77/0x7f

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&lruvec->lru_lock);
                               lock(lock#3);
                               lock(&lruvec->lru_lock);
  lock(lock#3);

 *** DEADLOCK ***

locks held by syz.0.17/5796: 5, last CPU#0:
 #0: ffff88810338ecf0 (&f->f_pos_lock){+.+.}-{4:4}, at: fdget_pos+0x246/0x320 fs/file.c:1259
 #1: ffff888110422460 (sb_writers#10){.+.+}-{0:0}, at: file_start_write include/linux/fs.h:2754 [inline]
 #1: ffff888110422460 (sb_writers#10){.+.+}-{0:0}, at: vfs_write+0x22b/0xba0 fs/read_write.c:683
 #2: ffff88811ad85880 (&of->mutex){+.+.}-{4:4}, at: kernfs_fop_write_iter+0x1d8/0x540 fs/kernfs/file.c:336
 #3: ffff8881bd86d3c8 (kn->active#53){.+.+}-{0:0}, at: kernfs_get_active_of fs/kernfs/file.c:73 [inline]
 #3: ffff8881bd86d3c8 (kn->active#53){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x22b/0x540 fs/kernfs/file.c:337
 #4: ffff888102ab6cb0 (&lruvec->lru_lock){....}-{3:3}, at: spin_lock_irq include/linux/spinlock.h:372 [inline]
 #4: ffff888102ab6cb0 (&lruvec->lru_lock){....}-{3:3}, at: evict_folios+0x3cf5/0x4970 mm/vmscan.c:4926

stack backtrace:
CPU: 0 UID: 0 PID: 5796 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) 
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
 <TASK>
 dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
 print_circular_bug+0x2e2/0x300 kernel/locking/lockdep.c:2059
 check_noncircular+0x12f/0x150 kernel/locking/lockdep.c:2191
 check_prev_add kernel/locking/lockdep.c:3181 [inline]
 check_prevs_add kernel/locking/lockdep.c:3300 [inline]
 validate_chain kernel/locking/lockdep.c:3924 [inline]
 __lock_acquire+0x15ff/0x2e50 kernel/locking/lockdep.c:5254
 lock_acquire+0x115/0x350 kernel/locking/lockdep.c:5908
 local_lock_acquire include/linux/local_lock_internal.h:46 [inline]
 __folio_batch_add_and_move+0x132/0xc50 mm/folio.c:220
 folio_putback_lru+0x18/0xe0 mm/vmscan.c:822
 evict_folios+0x3cfd/0x4970 mm/vmscan.c:4927
 try_to_shrink_lruvec+0xe3b/0x1340 mm/vmscan.c:5081
 lru_gen_shrink_lruvec mm/vmscan.c:5226 [inline]
 shrink_lruvec+0x54f/0x2c40 mm/vmscan.c:5986
 shrink_node_memcgs mm/vmscan.c:6225 [inline]
 shrink_node+0xa9b/0x3e30 mm/vmscan.c:6269
 shrink_zones mm/vmscan.c:6508 [inline]
 do_try_to_free_pages+0x6a3/0x1990 mm/vmscan.c:6570
 try_to_free_mem_cgroup_pages+0x30d/0x830 mm/vmscan.c:6892
 mem_cgroup_resize_max+0x23c/0x470 mm/memcontrol-v1.c:1817
 mem_cgroup_write+0x223/0x290 mm/memcontrol-v1.c:-1
 cgroup_file_write+0x331/0x8f0 kernel/cgroup/cgroup.c:4412
 kernfs_fop_write_iter+0x3a4/0x540 fs/kernfs/file.c:345
 new_sync_write fs/read_write.c:595 [inline]
 vfs_write+0x612/0xba0 fs/read_write.c:687
 ksys_write+0x150/0x270 fs/read_write.c:739
 do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
 do_syscall_64+0x166/0x510 arch/x86/entry/syscall_64.c:84
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f64a439e0d9
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f64a5333028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00007f64a4625fa0 RCX: 00007f64a439e0d9
RDX: 0000000000000020 RSI: 00002000000002c0 RDI: 0000000000000003
RBP: 00007f64a4435024 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007f64a4626038 R14: 00007f64a4625fa0 R15: 00007fff0f9eaaa8
 </TASK>


***

If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
  Tested-by: syzbot@syzkaller.appspotmail.com

---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.

To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).

The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2026-08-07 17:02 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-07 10:30 [PATCH] mm/mglru: fix lockless folio_putback_lru() race in evict_folios() Ketan Kishore
2026-08-07 15:12 ` Shakeel Butt
2026-08-07 17:02 ` [syzbot ci] " syzbot ci

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox