All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: syzbot <syzbot+789028412a4af61a2b61@syzkaller.appspotmail.com>
Cc: cem@kernel.org, linux-kernel@vger.kernel.org,
	linux-xfs@vger.kernel.org, mmpgouride@gmail.com,
	syzkaller-bugs@googlegroups.com,
	Brian Foster <bfoster@redhat.com>
Subject: Re: [syzbot] [xfs?] possible deadlock in xfs_icwalk_ag (3)
Date: Mon, 1 Dec 2025 23:40:03 -0800	[thread overview]
Message-ID: <aS6X08yD5yK8d8EG@infradead.org> (raw)
In-Reply-To: <692e499e.a70a0220.d98e3.0191.GAE@google.com>

This look like the batch zeroing code.  I think we have a patch pending
to remove the allocation, but I lost track a bit where we are with that.

On Mon, Dec 01, 2025 at 06:06:22PM -0800, syzbot wrote:
> 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.
> 
---end quoted text---

  reply	other threads:[~2025-12-02  7:40 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
2025-12-02  7:40   ` Christoph Hellwig [this message]
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=aS6X08yD5yK8d8EG@infradead.org \
    --to=hch@infradead.org \
    --cc=bfoster@redhat.com \
    --cc=cem@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mmpgouride@gmail.com \
    --cc=syzbot+789028412a4af61a2b61@syzkaller.appspotmail.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.