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@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. > > 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
