On Tue, 2006-12-26 at 01:08 +0059, Jiri Slaby wrote:
> Hi!
>
> * tty_flip_buffer_push - terminal
> * @tty: tty to push
> *
> * 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...
> Moreover, hvsi says:
> tty->low_latency = 1; /* avoid throttle/tty_flip_buffer_push race */
That was a long time ago, but the race is something like this:
* 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. I suppose most
PC-standard char drivers are not capable of overflowing a tty buffer
before the host can empty it. I wasn't comfortable with hoping for that
condition in my driver.
Setting "low_latency" ensures that throttle will be called immediately
if the tty buffer is filled, avoiding the race.
--
Hollis Blanchard
IBM Linux Technology Center
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
