linux-kernel - Re: [syzbot] [block?] possible deadlock in loop_set

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z0hkFoFsW5Xv8iKw@fedora>
Date: Thu, 28 Nov 2024 20:37:42 +0800
From: Ming Lei <ming.lei@...hat.com>
To: syzbot <syzbot+9b145229d11aa73e4571@...kaller.appspotmail.com>
Cc: axboe@...nel.dk, linux-block@...r.kernel.org,
	linux-kernel@...r.kernel.org, syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [block?] possible deadlock in loop_set_status

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