Re: INFO: task hung in __floppy_read_block_0

From: Denis Efremov <efremov@linux.com>
To: Willy Tarreau <w@1wt.eu>, Dipanjan Das <mail.dipanjan.das@gmail.com>
Cc: Lukas Bulwahn <lukas.bulwahn@gmail.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: Sun, 31 Jul 2022 14:46:30 +0400	[thread overview]
Message-ID: <b79b4f63-aa71-192c-54a9-6a8455bb9867@linux.com> (raw)
In-Reply-To: <20220731095307.GA12211@1wt.eu>

Hi,

On 7/31/22 13:53, Willy Tarreau wrote:
> Hi,
> 
> On Thu, Jul 28, 2022 at 01:20:33PM -0700, Dipanjan Das wrote:
>> On Thu, Jul 28, 2022 at 7:23 AM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
>>>
>>> Dipanjan, are you really sure that you want to report a "INFO: task
>>> hung" bug identified with your syzkaller instance? Especially for a
>>> floppy driver, probably in your case even just an emulated one
>>> (right?). Reading data from floppies was always very slow as far as I
>>> remember those times...
>>
>> >From the bugs reported by syzkaller in the past, we observed that
>> several of these "INFO: task hung in... " reports were considered and
>> acted on, for example, this:
>> https://groups.google.com/g/syzkaller-bugs/c/L0SBaHZ5bYc. For the
>> reported issue, we noticed the read task stays blocked for 143
>> seconds, which seemed to be one the higher, especially given that it
>> is an emulated floppy drive (yes, you are right). If it deems normal,
>> then we do apologize for our misassesment.
> 
> FWIW I've been running the repro here on machine running 5.19-rc8 and
> equipped with a real floppy drive. The code is still running as I type,
> it sounds like it's destroying the floppy disk in it but after 12 minutes
> of torture, nothing happens.
> 
> 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.

It's relatively easy to get "INFO: task hung ..." with the floppy driver.
The simplest way is to do "while (true) { close(open("/dev/fd0", ...)); }"
in multiple threads. Maybe with O_NBLOCK flag, I don't remember the exact
details. The timeout value to report task hung matters here (i.e.
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT). If you stop executing the cycle the
requests will be processed eventually. Floppy driver contains a number
of timeouts for hardware requests because hardware is slow. I would not
treat it as a thing to fix because: 1) a user faces it only if he tries
to fuzz the driver 2) it's easy to break something in the driver
(testing is hard and it doesn't cover all hardware/use-cases, real users
will notice if something broken only ~6 six months after distros will release
kernels with LTS patches) 3) floppy is not a security problem in modern
distros (/dev/fd0 access requires disk group or floppy group at least).

Null-ptr-deref reported recently is a different bug and I will look at it.
Last week I was out of my hardware with only limited access to the email
and I wasn't able to do it. Sorry for delays.

Thanks,
Denis