linux-kernel - Re: INFO: task hung in bdev

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] [thread-next>] [day] [month] [year] [list]

Date: Tue, 23 Apr 2024 14:51:51 +0800
From: Yu Kuai <yukuai1@...weicloud.com>
To: Marius Fleischer <fleischermarius@...il.com>, Jens Axboe
 <axboe@...nel.dk>, linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: syzkaller@...glegroups.com, harrisonmichaelgreen@...il.com,
 "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: INFO: task hung in bdev_open

Hi,

在 2024/04/21 9:19, Marius Fleischer 写道:
> INFO: task syz-executor.2:32444 blocked for more than 143 seconds.
>     Not tainted 6.9.0-rc4-dirty #3
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> task:syz-executor.2  state:D stack:25264 pid:32444 tgid:32417
> ppid:8232   flags:0x00004006
> Call Trace:
>   <TASK>
>   context_switch kernel/sched/core.c:5409 [inline]
>   __schedule+0xd23/0x5bc0 kernel/sched/core.c:6746
>   __schedule_loop kernel/sched/core.c:6823 [inline]
>   schedule+0xe7/0x350 kernel/sched/core.c:6838
>   io_schedule+0xbf/0x130 kernel/sched/core.c:9044
>   folio_wait_bit_common+0x397/0x9c0 mm/filemap.c:1283
>   folio_put_wait_locked mm/filemap.c:1447 [inline]
>   do_read_cache_folio+0x2db/0x520 mm/filemap.c:3729
>   read_mapping_folio include/linux/pagemap.h:894 [inline]
>   read_part_sector+0xf7/0x440 block/partitions/core.c:715
>   adfspart_check_POWERTEC+0x82/0x710 block/partitions/acorn.c:454
>   check_partition block/partitions/core.c:138 [inline]
>   blk_add_partitions block/partitions/core.c:582 [inline]
>   bdev_disk_changed+0x891/0x15f0 block/partitions/core.c:686
>   blkdev_get_whole+0x18b/0x260 block/bdev.c:667
>   bdev_open+0x2eb/0xe90 block/bdev.c:880
>   blkdev_open+0x181/0x200 block/fops.c:620
>   do_dentry_open+0x6d3/0x18e0 fs/open.c:955
>   do_open fs/namei.c:3642 [inline]
>   path_openat+0x1b23/0x2670 fs/namei.c:3799
>   do_filp_open+0x1c7/0x410 fs/namei.c:3826
>   do_sys_openat2+0x164/0x1d0 fs/open.c:1406
>   do_sys_open fs/open.c:1421 [inline]
>   __do_sys_openat fs/open.c:1437 [inline]
>   __se_sys_openat fs/open.c:1432 [inline]
>   __x64_sys_openat+0x140/0x1f0 fs/open.c:1432
>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>   do_syscall_64+0xce/0x250 arch/x86/entry/common.c:83
>   entry_SYSCALL_64_after_hwframe+0x77/0x7f

So this thread hold 'open_mutex' to issued IO to scan partitons, and
such IO never complete, consider that you are using nbd to test, and
nbd doesn't handle timeout by default, I really suspect this is not a
real issue, and this looks like nbd server side doesn't reply to
nbd-client.

Thanks,
Kuai