Received-SPF: pass (google.com: domain of linux-kernel+bounces-157137-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Precedence: bulk
MIME-Version: 1.0
References: <CAJg=8jyC1+s80etZgWteps0Q0yEsR2NE23+Bf+Daa7zgJ2qKBA@mail.gmail.com>
 <2c9182cc-9d7e-0108-90bc-5e66da966bdb@huaweicloud.com>
In-Reply-To: <2c9182cc-9d7e-0108-90bc-5e66da966bdb@huaweicloud.com>
From: Marius Fleischer <fleischermarius@gmail.com>
Date: Wed, 24 Apr 2024 07:54:06 -0700
Message-ID: <CAJg=8jwn5NDWmo4=prnFbZJuq7N3kdmt2evkQ9uEJCWi0Bs8dg@mail.gmail.com>
Subject: Re: INFO: task hung in bdev_open
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: Jens Axboe <axboe@kernel.dk>, linux-block@vger.kernel.org, 
	linux-kernel@vger.kernel.org, syzkaller@googlegroups.com, 
	harrisonmichaelgreen@gmail.com, "yukuai (C)" <yukuai3@huawei.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Kuai,

I see, thanks so much for the explanation!

Best,
Marius

On Mon, 22 Apr 2024 at 23:51, Yu Kuai <yukuai1@huaweicloud.com> wrote:
>
> Hi,
>
> =E5=9C=A8 2024/04/21 9:19, Marius Fleischer =E5=86=99=E9=81=93:
> > 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 messag=
e.
> > 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
>