Received-SPF: pass (google.com: domain of linux-kernel+bounces-154575-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Subject: Re: INFO: task hung in bdev_open
To: Marius Fleischer <fleischermarius@gmail.com>, Jens Axboe
 <axboe@kernel.dk>, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: syzkaller@googlegroups.com, harrisonmichaelgreen@gmail.com,
 "yukuai (C)" <yukuai3@huawei.com>
References: <CAJg=8jyC1+s80etZgWteps0Q0yEsR2NE23+Bf+Daa7zgJ2qKBA@mail.gmail.com>
From: Yu Kuai <yukuai1@huaweicloud.com>
Message-ID: <2c9182cc-9d7e-0108-90bc-5e66da966bdb@huaweicloud.com>
Date: Tue, 23 Apr 2024 14:51:51 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <CAJg=8jyC1+s80etZgWteps0Q0yEsR2NE23+Bf+Daa7zgJ2qKBA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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