Re: [PATCH] hvc_console fix to protect hvc_write against ldisc write after hvc_close

[Ryan Arnold <rsa@us.ibm.com>]

On Wed, 2004-09-15 at 14:20, Alan Cox wrote:
> Actually for the short term I may have made the ldisc calling tty race
> worse. I'm still looking into some of that. I've fixed the one the other
> way but for now driver defensively 8)

Alan, thanks for the heads up, and thanks for the work on the ldisc code
it is MUCH appreciated.

While we're looking at the ldisc code; I am a bit disturbed by how easy
it is to tty_flip_buffer_push() and silently lose data.  The ldisc
function n_tty_receive_buf() which is normally scheduled as delayed work
via the tty_flip_buffer_push() operation simply overwrites the contents
of the circular tty->read_buf leading to dataloss and out of order
output if too much data is pushed too quickly.

The manual accounting of pushed data is very tricky to do when the
pushing thread isn't sure of when the line discipline will actually
schedule the n_tty_receive_buf() operation.  I think that the tty
throttle() & unthrottle api is supposed to help with this but it is
possible (and in my experience was common) that the throttle callback
would happen AFTER data has already been lost.

Many of us tty driver writers resort to setting tty->low_latency = 1
which synchronizes the n_tty_receive_buf() call to be executed in the
same thread as that which invoked tty_flip_buffer_push() such that we
know when a throttle happens we haven't yet lost data.

I don't know when tty->low_latency is really appropriate to use but it
solves my problems.  I've heard people say that tty data delivery is
inherently unreliable.  This doesn't make sense to me because imho tty
data is very important.  I hope I'm not approaching this topic of
flip_buffer_pushing and throttling from a mistaken assumption.

Thanks,

Ryan S. Arnold
Linux Technology Center