From: Willy Tarreau <w@1wt.eu>
To: Dipanjan Das <mail.dipanjan.das@gmail.com>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com>,
Denis Efremov <efremov@linux.com>, Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
syzkaller <syzkaller@googlegroups.com>,
fleischermarius@googlemail.com, its.priyanka.bose@gmail.com
Subject: Re: INFO: task hung in __floppy_read_block_0
Date: Tue, 2 Aug 2022 18:50:02 +0200 [thread overview]
Message-ID: <20220802165002.GA21797@1wt.eu> (raw)
In-Reply-To: <CANX2M5YxE31gSU804jm6U4T6uTeCTjgk1gfHM+ockpjHnXfDrw@mail.gmail.com>
Hi,
On Mon, Aug 01, 2022 at 10:04:46PM -0700, Dipanjan Das wrote:
> On Sun, Jul 31, 2022 at 2:53 AM Willy Tarreau <w@1wt.eu> wrote:
> >
> > Thus I'm a bit confused about what to look for. It's very likely that
> > there are still bugs left in this driver, but trying to identify them
> > and to validate a fix will be difficult if they cannot be reproduced.
> > Maybe they only happen under emulation due to timing issues.
> >
> > As such, any hint about the exact setup and how long to wait to get
> > the error would be much appreciated.
>
> We can confirm that we were able to trigger the issue on the latest
> 5.19 (commit: 3d7cb6b04c3f3115719235cc6866b10326de34cd) with the
> C-repro within a VM. We use this:
> https://syzkaller.appspot.com/text?tag=KernelConfig&x=cd73026ceaed1402
> config to build the kernel. The issue triggers after around 143
> seconds. For all the five times we tried, we were able to reproduce
> the issue deterministically every time. Please let us know if you need
> any other information.
Yep, I could reproduce it under qemu as well. I've added traces, and
ugly things are happening with the lock (but I haven't understood what
yet). What I saw was that process_fd_request() is first called under
lock, then we drop the lock, then __floppy_read_block_0() is called
under lock, which calls process_fd_request(), then the lock is dropped,
wait_for_completion() is called, then process_fd_request() is called
again without lock this time, and from there we're looping in
fd_wait_for_completion. I need to dig into more details but it doesn't
seem right to me that process_fd_request() is sometimes called under a
lock and sometimes out, and that __floppy_read_block_0() is called with
a lock held and it's relesed under it. I could have missed certain things
due to the concurrent accesses but in any case I should probably not be
observing this.
I'll try to dig deeper. I really don't know that area and I must confess
it's not the most exciting to rediscover each time :-)
Thanks,
Willy
prev parent reply other threads:[~2022-08-02 16:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-27 22:00 INFO: task hung in __floppy_read_block_0 Dipanjan Das
2022-07-28 14:23 ` Lukas Bulwahn
2022-07-28 20:20 ` Dipanjan Das
2022-07-29 14:32 ` Lukas Bulwahn
2022-07-31 9:53 ` Willy Tarreau
2022-07-31 10:46 ` Denis Efremov
2022-08-02 5:04 ` Dipanjan Das
2022-08-02 16:50 ` Willy Tarreau [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220802165002.GA21797@1wt.eu \
--to=w@1wt.eu \
--cc=axboe@kernel.dk \
--cc=efremov@linux.com \
--cc=fleischermarius@googlemail.com \
--cc=its.priyanka.bose@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukas.bulwahn@gmail.com \
--cc=mail.dipanjan.das@gmail.com \
--cc=syzkaller@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).