Message-ID: <CANX2M5b9PBp9i5v_akXshQqBFRT4dTHg+PR2pWpHPa5RBOEUTg@mail.gmail.com>
Date:   Thu, 28 Jul 2022 13:20:33 -0700
From:   Dipanjan Das <mail.dipanjan.das@...il.com>
To:     Lukas Bulwahn <lukas.bulwahn@...il.com>
Cc:     Denis Efremov <efremov@...ux.com>, Jens Axboe <axboe@...nel.dk>,
        linux-block@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        syzkaller <syzkaller@...glegroups.com>,
        fleischermarius@...glemail.com, its.priyanka.bose@...il.com
Subject: Re: INFO: task hung in __floppy_read_block_0

On Thu, Jul 28, 2022 at 7:23 AM Lukas Bulwahn <lukas.bulwahn@...il.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.

> Consider the severity of the issue and judge if you would like to
> point out such a 'bug'.
>
> It might happen that:
>
> Due to bad judgement on your side, kernel developers and maintainers
> will consider the value/severity of the provided bug reports overall
> and then eventually simply ignore all reports that you send.

That would be very unfortunate. Please allow me to explain how we, as
a *small* academic team, are operating. If you closely follow our
reportings we did in the last few days, the first “quality control” we
are doing (to minimize the noise and frustration) is to make sure not
to report any bug without a reproducer. Now, the unfortunate reality
is that none of us is a pro kernel hacker with years of expertise in
tinkering with Linux internals, which essentially means, no matter how
hard we try, we cannot simply match up the combined level of expertise
and competency of the people in these mailing groups. We are using our
best judgement before reporting these bugs. Admittedly, we may be
wrong, and we apologize in advance for such mishaps. The developers
can confirm, or refute the reports (if they can spend a line or two
why they think something we reported is not a problem, we would be
grateful). In our defense, what we can say is that, in the last few
days we responded to the developers who asked us to provide details of
a bug, or test a patch. In fact, we are still in the process of
responding to some of them, because being a small team, our turnaround
time is higher than ideal. To answer you, simply ignoring all the
reports we send might be too harsh (unfair?) to an academic group
operating in good faith. Providing us pointers like you did above
(thanks to Greg for helping us in some other thread), and letting us
know what we did wrong will help us to align ourselves better with the
reporting and patching workflow.

> Dmitry and his team around syzkaller and syzbot can give you more
> insights on learning a good judgement of what to report, how and when.

We would very much appreciate any help (even positive criticism) from
the community in this regard.

-- 
Thanks and Regards,

Dipanjan

Powered by blists - more mailing lists