Re: [syzbot] [block?] possible deadlock in loop_set_status

Ming Lei
2024-11-28T12:37:59Z

On Sat, Nov 23, 2024 at 06:42:24AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 06afb0f36106 Merge tag 'trace-v6.13' of git://git.kernel.o..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=125a81c0580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=95b76860fd16c857
> dashboard link: https://syzkaller.appspot.com/bug?extid=9b145229d11aa73e4571
> compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
>
> Unfortunately, I don't have any reproducer for this issue yet.

This one is supposed to be reproduced 100%, :-(

>
> -> #0 (fs_reclaim){+.+.}-{0:0}:
> check_prev_add kernel/locking/lockdep.c:3161 [inline]
> check_prevs_add kernel/locking/lockdep.c:3280 [inline]
> validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904
> __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226
> lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849
> __fs_reclaim_acquire mm/page_alloc.c:3851 [inline]
> fs_reclaim_acquire+0x88/0x130 mm/page_alloc.c:3865
> might_alloc include/linux/sched/mm.h:318 [inline]
> slab_pre_alloc_hook mm/slub.c:4036 [inline]
> slab_alloc_node mm/slub.c:4114 [inline]
> __kmalloc_cache_noprof+0x3d/0x2c0 mm/slub.c:4290
> kmalloc_noprof include/linux/slab.h:879 [inline]
> kzalloc_noprof include/linux/slab.h:1015 [inline]
> kobject_uevent_env+0x28b/0x8e0 lib/kobject_uevent.c:540
> set_capacity_and_notify+0x206/0x240 block/genhd.c:95
> loop_set_size drivers/block/loop.c:232 [inline]
> loop_set_status+0x584/0x8f0 drivers/block/loop.c:1285
> lo_ioctl+0xcbc/0x1f50
> blkdev_ioctl+0x57d/0x6a0 block/ioctl.c:693
> vfs_ioctl fs/ioctl.c:51 [inline]
> __do_sys_ioctl fs/ioctl.c:906 [inline]
> __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892
> do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
> entry_SYSCALL_64_after_hwframe+0x77/0x7f

Looks one real deadlock because bio_queue_enter() may be called from
direct reclaim, which is under blk_mq_freeze_queue().

thanks,
Ming