Messages in this thread | | | Subject | Re: [PATCH] hvc_console fix to protect hvc_write against ldisc write after hvc_close | From | Ryan Arnold <> | Date | Wed, 15 Sep 2004 16:23:02 -0500 |
| |
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
- 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/
| |