On Tue, 2007-01-02 at 11:17 -0600, Hollis Blanchard wrote: > On Tue, 2006-12-26 at 01:08 +0059, Jiri Slaby wrote: > > * Queue a push of the terminal flip buffers to the line discipline. > > This > > * function must not be called from IRQ context if tty->low_latency is > > set. > > > > But some drivers (mxser, nozomi, hvsi...) sets low_latency to 1 in _open and > > calls tty_flip_buffer_push in isr or in functions, which are called from > > isr. > > Is the comment correct or the drivers? > > The comment would be true if tty_flip_buffer_push() attempted to block > 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...
There is no deadlock on tty->buf.lock, which is always acquired with spin_lock_irqsave() and is only used by the tty buffering code. The only deadlock I know of with the current tty buffering code is calling tty_flip_buffer_push() with low_latency set and from the ISR of a driver that has a problem with the line discipline calling back into the driver. The standard serial core has (or at least had the last time I looked) this problem with the N_TTY ldisc: driver gets internal spinlock in ISR driver calls tty_flip_buffer_push with low_latency = 1 flush_to_ldisc() immediately passes data to line discipline line discipline calls back into driver driver tries again to get internal spinlock With low_latency == 1, flush_to_ldisc() is deferred until the ISR is complete and the internal spinlock is released. I forget the exact driver callback that caused this. -- Paul Fulghum Microgate Systems, Ltd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/