On Fri, 19 Aug 2011 20:44:26 +0000 (UTC) Grant Edwards <grant.b.edwards@xxxxxxxxx> wrote: > On 2011-08-19, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: > > >> But, many drivers appear to call tty_flip_buffer_push() from an atomic > >> context. If that is done with tty->low_latency==1 it turns into a call > >> to flush_to_ldisc(), which then calls disc->ops->receive_buf(), which > >> must not be called from an atomic context. > > > > It's covered under "So don't do that then". > > I don't do that, and wasn't asking if I should. > > My point was that most of the drivers in the linux kernels sources > _do_ appear to do that, and I don't see how they avoid problems. > > For exaple, 8250.c calls tty_flip_buffer_push() from receive_chars(), > calld from serial8250_handle_port(), called from > serial8250_interrupt(). > > How are problems avoided when tty->low_latency is set? > > Is tty->low_latency never allowed to be set for the 8250 driver? Several drivers certainly allow someone with superuser privileges to misconfigure them. I've never worried about chasing all those down. It might actually be worth supporting a tty->low_latency mode which uses a tty layer private workqueue that is set to real time priority rather than the system work queue. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
