On Friday 21 August 2009, Alan Cox wrote: > > That patch made an incompatible change to the locking policy, so that > > combining (a) tty->low_latency with (b) tty_flip_buffer_push() calls > > from tasklets now generates lockdep warnings of the "you can't grab a > > mutex from a tasklet" flavor. > > No it didn't. In an operational sense it most certainly did. And that's how regressions are normally measured: it worked before, but now doesn't work. Docs != code and all that. > The low_latency combined with flip_buffer_push has always > been forbidden (and documented so) since the day the flag was added. It > just didn't use to spew diagnostics. So this code has been broken forever. In the sense of "latent bug", I might agree. ISTR there was some kind of bug tradeoff back then: changing that (which was not observed to be trouble) broke something common. Don't recall the details though; I was probably trying to edit the TTY layer out of my grey cells. ;) > > * REVISIT we should probably add a timer to keep the tasklet > > - * from starving ... but it's not clear that case ever happens. > > + * from starving: not throttled, but TTY layer is refusing data. > > + * This was observed on 2.6.27-rc1 when streaming megabytes of > > + * data down a raw pipe... > > The throttle race was recently fixed and was real (although you probably > saw it in real life because you wrongly set tty->low_latency). You could > get this occuring the throttle and unthrottle running at the same time Sounds like that required SMP? I saw this on a single-core ARM. > which meant the driver could see the unthrottle callback occur before the > throttle it matched. The fix for this amusingly is the patch which caught > the driver misusing tty->low_latency. Good to know. I'll leave that comment, pending re-testing against more current TTY code. Stress loads (more TX than RX) had glitches which seemed likely to be affected by the overhaul you were very actively working on at the time. (And thanks for wading in and fixing so much of that pile of TTY ... stuff!) - Dave -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
