O> 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. 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. > * 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 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. > - /* low_latency means ldiscs work in tasklet context, without > - * needing a workqueue schedule ... easier to keep up. > - */ > - tty->low_latency = 1; low_latency was and is for avoiding latency. The issues about buffering which people abused it for were fixed some releases ago when the tty_buffer patches were merged. [I blame GregKH, people keep quoting his old LJ article ;)] Alan -- 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
