From: syzbot <syzbot+789028412a4af61a2b61@syzkaller.appspotmail.com>
To: cem@kernel.org, linux-kernel@vger.kernel.org,
linux-xfs@vger.kernel.org, mmpgouride@gmail.com,
syzkaller-bugs@googlegroups.com
Subject: Re: [syzbot] [xfs?] possible deadlock in xfs_icwalk_ag (3)
Date: Mon, 01 Dec 2025 18:06:22 -0800 [thread overview]
Message-ID: <692e499e.a70a0220.d98e3.0191.GAE@google.com> (raw)
In-Reply-To: <689a0c9f.050a0220.51d73.009e.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 1d18101a644e Merge tag 'kernel-6.19-rc1.cred' of git://git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=119238c2580000
kernel config: https://syzkaller.appspot.com/x/.config?x=a1db0fea040c2a9f
dashboard link: https://syzkaller.appspot.com/bug?extid=789028412a4af61a2b61
compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1407a512580000
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-1d18101a.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/98f78b52cccd/vmlinux-1d18101a.xz
kernel image: https://storage.googleapis.com/syzbot-assets/7a8898061bfb/bzImage-1d18101a.xz
mounted in repro: https://storage.googleapis.com/syzbot-assets/9f625d767816/mount_0.gz
fsck result: failed (log: https://syzkaller.appspot.com/x/fsck.log?x=1406a192580000)
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+789028412a4af61a2b61@syzkaller.appspotmail.com
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
kswapd0/73 is trying to acquire lock:
ffff88804146c118 (&xfs_nondir_ilock_class){++++}-{4:4}, at: xfs_reclaim_inode fs/xfs/xfs_icache.c:1040 [inline]
ffff88804146c118 (&xfs_nondir_ilock_class){++++}-{4:4}, at: xfs_icwalk_process_inode fs/xfs/xfs_icache.c:1732 [inline]
ffff88804146c118 (&xfs_nondir_ilock_class){++++}-{4:4}, at: xfs_icwalk_ag+0x12c5/0x1ab0 fs/xfs/xfs_icache.c:1814
but task is already holding lock:
ffffffff8e047ae0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat mm/vmscan.c:7015 [inline]
ffffffff8e047ae0 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x951/0x2800 mm/vmscan.c:7389
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (fs_reclaim){+.+.}-{0:0}:
lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868
__fs_reclaim_acquire mm/page_alloc.c:4264 [inline]
fs_reclaim_acquire+0x72/0x100 mm/page_alloc.c:4278
might_alloc include/linux/sched/mm.h:318 [inline]
slab_pre_alloc_hook mm/slub.c:4929 [inline]
slab_alloc_node mm/slub.c:5264 [inline]
__kmalloc_cache_noprof+0x40/0x6f0 mm/slub.c:5766
kmalloc_noprof include/linux/slab.h:957 [inline]
iomap_fill_dirty_folios+0xf4/0x260 fs/iomap/buffered-io.c:1557
xfs_buffered_write_iomap_begin+0xa23/0x1a70 fs/xfs/xfs_iomap.c:1857
iomap_iter+0x5f2/0xf10 fs/iomap/iter.c:110
iomap_zero_range+0x1cc/0xa50 fs/iomap/buffered-io.c:1590
xfs_zero_range+0x9a/0x100 fs/xfs/xfs_iomap.c:2289
xfs_reflink_remap_prep+0x398/0x720 fs/xfs/xfs_reflink.c:1699
xfs_file_remap_range+0x235/0x780 fs/xfs/xfs_file.c:1518
vfs_copy_file_range+0xd81/0x1370 fs/read_write.c:1598
__do_sys_copy_file_range fs/read_write.c:1681 [inline]
__se_sys_copy_file_range+0x2fb/0x470 fs/read_write.c:1648
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&xfs_nondir_ilock_class){++++}-{4:4}:
check_prev_add kernel/locking/lockdep.c:3165 [inline]
check_prevs_add kernel/locking/lockdep.c:3284 [inline]
validate_chain+0xb9b/0x2140 kernel/locking/lockdep.c:3908
__lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5237
lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868
down_write_nested+0x9d/0x200 kernel/locking/rwsem.c:1706
xfs_reclaim_inode fs/xfs/xfs_icache.c:1040 [inline]
xfs_icwalk_process_inode fs/xfs/xfs_icache.c:1732 [inline]
xfs_icwalk_ag+0x12c5/0x1ab0 fs/xfs/xfs_icache.c:1814
xfs_icwalk fs/xfs/xfs_icache.c:1862 [inline]
xfs_reclaim_inodes_nr+0x1e3/0x260 fs/xfs/xfs_icache.c:1106
super_cache_scan+0x41b/0x4b0 fs/super.c:228
do_shrink_slab+0x6ef/0x1110 mm/shrinker.c:437
shrink_slab+0xd74/0x10d0 mm/shrinker.c:664
shrink_one+0x28a/0x7c0 mm/vmscan.c:4955
shrink_many mm/vmscan.c:5016 [inline]
lru_gen_shrink_node mm/vmscan.c:5094 [inline]
shrink_node+0x315d/0x3780 mm/vmscan.c:6081
kswapd_shrink_node mm/vmscan.c:6941 [inline]
balance_pgdat mm/vmscan.c:7124 [inline]
kswapd+0x147c/0x2800 mm/vmscan.c:7389
kthread+0x711/0x8a0 kernel/kthread.c:463
ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(&xfs_nondir_ilock_class);
lock(fs_reclaim);
lock(&xfs_nondir_ilock_class);
*** DEADLOCK ***
2 locks held by kswapd0/73:
#0: ffffffff8e047ae0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat mm/vmscan.c:7015 [inline]
#0: ffffffff8e047ae0 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x951/0x2800 mm/vmscan.c:7389
#1: ffff8880119bc0e0 (&type->s_umount_key#54){++++}-{4:4}, at: super_trylock_shared fs/super.c:563 [inline]
#1: ffff8880119bc0e0 (&type->s_umount_key#54){++++}-{4:4}, at: super_cache_scan+0x91/0x4b0 fs/super.c:197
stack backtrace:
CPU: 0 UID: 0 PID: 73 Comm: kswapd0 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
print_circular_bug+0x2ee/0x310 kernel/locking/lockdep.c:2043
check_noncircular+0x134/0x160 kernel/locking/lockdep.c:2175
check_prev_add kernel/locking/lockdep.c:3165 [inline]
check_prevs_add kernel/locking/lockdep.c:3284 [inline]
validate_chain+0xb9b/0x2140 kernel/locking/lockdep.c:3908
__lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5237
lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868
down_write_nested+0x9d/0x200 kernel/locking/rwsem.c:1706
xfs_reclaim_inode fs/xfs/xfs_icache.c:1040 [inline]
xfs_icwalk_process_inode fs/xfs/xfs_icache.c:1732 [inline]
xfs_icwalk_ag+0x12c5/0x1ab0 fs/xfs/xfs_icache.c:1814
xfs_icwalk fs/xfs/xfs_icache.c:1862 [inline]
xfs_reclaim_inodes_nr+0x1e3/0x260 fs/xfs/xfs_icache.c:1106
super_cache_scan+0x41b/0x4b0 fs/super.c:228
do_shrink_slab+0x6ef/0x1110 mm/shrinker.c:437
shrink_slab+0xd74/0x10d0 mm/shrinker.c:664
shrink_one+0x28a/0x7c0 mm/vmscan.c:4955
shrink_many mm/vmscan.c:5016 [inline]
lru_gen_shrink_node mm/vmscan.c:5094 [inline]
shrink_node+0x315d/0x3780 mm/vmscan.c:6081
kswapd_shrink_node mm/vmscan.c:6941 [inline]
balance_pgdat mm/vmscan.c:7124 [inline]
kswapd+0x147c/0x2800 mm/vmscan.c:7389
kthread+0x711/0x8a0 kernel/kthread.c:463
ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
next prev parent reply other threads:[~2025-12-02 2:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-11 15:30 [syzbot] [xfs?] possible deadlock in xfs_icwalk_ag (3) syzbot
2025-08-11 17:03 ` Alan Huang
2025-12-02 2:06 ` syzbot [this message]
2025-12-02 7:40 ` Christoph Hellwig
2025-12-02 3:35 ` syzbot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=692e499e.a70a0220.d98e3.0191.GAE@google.com \
--to=syzbot+789028412a4af61a2b61@syzkaller.appspotmail.com \
--cc=cem@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mmpgouride@gmail.com \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.