Re: tty->low_latency + irq context

[Paul Fulghum <paulkf@microgate.com>]

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