[lkml]   [2007]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: tty->low_latency + irq context
    > 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...

    The case to watch out for is

    flip_buffer_push -> ldisc -> driver write of echo/^S/^Q

    if you call flip_buffer_push while holding your own lock you may get in
    a mess on the echo path.

    > * 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.

    For non fake tty hardware at real speeds it wasn't a problem under about
    1Mbit. Current tty layer code just uses memory buffering based on kmalloc
    and has a 64K limit instead. Works better SMP, scales better and we no
    longer need to do stunts like the flip buffers to scrape 56Kbit on a

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-01-02 19:31    [W:2.680 / U:0.032 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site