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: Windows password security audit tool. GUI, reports in PDF.

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

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

Hi Kuai,

I see, thanks so much for the explanation!

Best,
Marius

On Mon, 22 Apr 2024 at 23:51, Yu Kuai <yukuai1@...weicloud.com> wrote:
>
> 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
>