Messages in this thread | | | Date | Tue, 2 Jan 2007 18:38:29 +0000 | From | Alan <> | Subject | Re: tty->low_latency + irq context |
| |
> with tty->low_latency set, but it doesn't AFAICS. One possibility for > deadlock is if the tty->buf.lock spinlock is taken on behalf of a user > process...
The case to watch out for is
flip_buffer_push -> ldisc -> driver write of echo/^S/^Q
if you call flip_buffer_push while holding your own lock you may get in a mess on the echo path.
> * data is received, enough to completely fill the tty buffer > * tty_flip_buffer_push() schedules flush_to_ldisc() > * before flush_to_ldisc() runs, more data is received > * flush_to_ldisc() truncates the incoming data (look for > tty->receive_room) > > I don't see how this is supposed to work in general.
For non fake tty hardware at real speeds it wasn't a problem under about 1Mbit. Current tty layer code just uses memory buffering based on kmalloc and has a 64K limit instead. Works better SMP, scales better and we no longer need to do stunts like the flip buffers to scrape 56Kbit on a 386SX16
Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |