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