On Fri, 21 Aug 2009 12:27:10 -0700 David Brownell <david-b@xxxxxxxxxxx> wrote: > 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. Not really - it would randomly corrupt or call functions in unsafe ways. > > 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. It didn't require SMP: this is what could occur (especially with low_latency mis-set. Without it I think you really did need SMP) tty_throttle set throttled INT ldisc processing tty_unthrottle ->unthrottle INT over ->throttle ... hang > 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!) Other than the throttle race tx ought to be pretty solid. Ditto rx once the tty buffer stuff was in. open/close/hangup is however still not a pretty story. -- 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
