| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <695c4619.050a0220.318c5c.0134.GAE@google.com>
Date: Mon, 05 Jan 2026 15:15:37 -0800
From: syzbot <syzbot+c628140f24c07eb768d8@...kaller.appspotmail.com>
To: david@...morbit.com
Cc: cem@...nel.org, david@...morbit.com, linux-kernel@...r.kernel.org,
linux-xfs@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [xfs?] possible deadlock in xfs_ilock (4)
> On Sun, Jan 04, 2026 at 06:40:21PM -0800, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit: 8f0b4cce4481 Linux 6.19-rc1
>> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1481d792580000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=8a8594efdc14f07a
>> dashboard link: https://syzkaller.appspot.com/bug?extid=c628140f24c07eb768d8
>> compiler: Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
>> userspace arch: arm64
>>
>> Unfortunately, I don't have any reproducer for this issue yet.
>>
>> Downloadable assets:
>> disk image: https://storage.googleapis.com/syzbot-assets/cd4f5f43efc8/disk-8f0b4cce.raw.xz
>> vmlinux: https://storage.googleapis.com/syzbot-assets/aafb35ac3a3c/vmlinux-8f0b4cce.xz
>> kernel image: https://storage.googleapis.com/syzbot-assets/d221fae4ab17/Image-8f0b4cce.gz.xz
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: syzbot+c628140f24c07eb768d8@...kaller.appspotmail.com
>>
>> WARNING: possible circular locking dependency detected
>> syzkaller #0 Not tainted
>> ------------------------------------------------------
>> syz.3.4/6790 is trying to acquire lock:
>> ffff80008fb56c80 (fs_reclaim){+.+.}-{0:0}, at: might_alloc include/linux/sched/mm.h:317 [inline]
>> ffff80008fb56c80 (fs_reclaim){+.+.}-{0:0}, at: slab_pre_alloc_hook mm/slub.c:4904 [inline]
>> ffff80008fb56c80 (fs_reclaim){+.+.}-{0:0}, at: slab_alloc_node mm/slub.c:5239 [inline]
>> ffff80008fb56c80 (fs_reclaim){+.+.}-{0:0}, at: __kmalloc_cache_noprof+0x58/0x698 mm/slub.c:5771
>>
>> but task is already holding lock:
>> ffff0000f77f5b18 (&xfs_nondir_ilock_class){++++}-{4:4}, at: xfs_ilock+0x1d8/0x3d0 fs/xfs/xfs_inode.c:165
>>
>> which lock already depends on the new lock.
>
> #syz test
This crash does not have a reproducer. I cannot test it.
>
>
> iomap: use mapping_gfp_mask() for iomap_fill_dirty_folios()
>
> From: Dave Chinner <dchinner@...hat.com>
>
> GFP_KERNEL allocations in the buffered write path generates false
> positive lockdep warnings against inode reclaim such as:
>
> -> #1 (&xfs_nondir_ilock_class){++++}-{4:4}:
> down_write_nested+0x58/0xcc kernel/locking/rwsem.c:1706
> xfs_ilock+0x1d8/0x3d0 fs/xfs/xfs_inode.c:165
> xfs_reclaim_inode fs/xfs/xfs_icache.c:1035 [inline]
> xfs_icwalk_process_inode fs/xfs/xfs_icache.c:1727 [inline]
> xfs_icwalk_ag+0xe4c/0x16a4 fs/xfs/xfs_icache.c:1809
> xfs_icwalk fs/xfs/xfs_icache.c:1857 [inline]
> xfs_reclaim_inodes_nr+0x1b4/0x268 fs/xfs/xfs_icache.c:1101
> xfs_fs_free_cached_objects+0x68/0x7c fs/xfs/xfs_super.c:1282
> super_cache_scan+0x2f0/0x380 fs/super.c:228
> do_shrink_slab+0x638/0x11b0 mm/shrinker.c:437
> shrink_slab+0xc68/0xfb8 mm/shrinker.c:664
> shrink_node_memcgs mm/vmscan.c:6022 [inline]
> shrink_node+0xe18/0x20bc mm/vmscan.c:6061
> kswapd_shrink_node mm/vmscan.c:6901 [inline]
> balance_pgdat+0xb60/0x13b8 mm/vmscan.c:7084
> kswapd+0x6d0/0xe64 mm/vmscan.c:7354
> kthread+0x5fc/0x75c kernel/kthread.c:463
> ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:844
>
> -> #0 (fs_reclaim){+.+.}-{0:0}:
> check_prev_add kernel/locking/lockdep.c:3165 [inline]
> check_prevs_add kernel/locking/lockdep.c:3284 [inline]
> validate_chain kernel/locking/lockdep.c:3908 [inline]
> __lock_acquire+0x1774/0x30a4 kernel/locking/lockdep.c:5237
> lock_acquire+0x140/0x2e0 kernel/locking/lockdep.c:5868
> __fs_reclaim_acquire mm/page_alloc.c:4301 [inline]
> fs_reclaim_acquire+0x8c/0x118 mm/page_alloc.c:4315
> might_alloc include/linux/sched/mm.h:317 [inline]
> slab_pre_alloc_hook mm/slub.c:4904 [inline]
> slab_alloc_node mm/slub.c:5239 [inline]
> __kmalloc_cache_noprof+0x58/0x698 mm/slub.c:5771
> kmalloc_noprof include/linux/slab.h:957 [inline]
> iomap_fill_dirty_folios+0xf0/0x218 fs/iomap/buffered-io.c:1557
> xfs_buffered_write_iomap_begin+0x8b4/0x1668 fs/xfs/xfs_iomap.c:1857
> iomap_iter+0x528/0xefc fs/iomap/iter.c:110
> iomap_zero_range+0x17c/0x8ec fs/iomap/buffered-io.c:1590
> xfs_zero_range+0x98/0xfc fs/xfs/xfs_iomap.c:2289
> xfs_reflink_zero_posteof+0x110/0x2f0 fs/xfs/xfs_reflink.c:1619
> xfs_reflink_remap_prep+0x314/0x5e4 fs/xfs/xfs_reflink.c:1699
> xfs_file_remap_range+0x1f4/0x758 fs/xfs/xfs_file.c:1518
> vfs_clone_file_range+0x62c/0xb68 fs/remap_range.c:403
> ioctl_file_clone fs/ioctl.c:239 [inline]
> ioctl_file_clone_range fs/ioctl.c:257 [inline]
> do_vfs_ioctl+0xb84/0x1834 fs/ioctl.c:544
>
> We use mapping_gfp_mask() in the IO paths where the IOLOCK is held
> to avoid these false positives and any possible reclaim recursion
> deadlock that might occur from complex nested calls into the IO
> path.
>
> Fixes: 395ed1ef0012 ("iomap: optional zero range dirty folio processing")
> Reported-by: syzbot+c628140f24c07eb768d8@...kaller.appspotmail.com
> Signed-off-by: Dave Chinner <dchinner@...hat.com>
> ---
> fs/iomap/buffered-io.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
> index e5c1ca440d93..01f0263e285a 100644
> --- a/fs/iomap/buffered-io.c
> +++ b/fs/iomap/buffered-io.c
> @@ -1554,7 +1554,8 @@ iomap_fill_dirty_folios(
> pgoff_t start = offset >> PAGE_SHIFT;
> pgoff_t end = (offset + length - 1) >> PAGE_SHIFT;
>
> - iter->fbatch = kmalloc(sizeof(struct folio_batch), GFP_KERNEL);
> + iter->fbatch = kmalloc(sizeof(struct folio_batch),
> + mapping_gfp_mask(mapping));
> if (!iter->fbatch)
> return offset + length;
> folio_batch_init(iter->fbatch);
Powered by blists - more mailing lists