Greg, This series fixes a long-standing problem with Ctrl-C interruption of pty output. A while back I tried to fix this in a really ugly way that Alan ixnay'd. Quick background: the FIXME in pty_flush_buffer() relates to the potential for deadlock if tty_buffer_flush() is done in parallel by both ptys. The two potential sources for deadlock were the tty->ldisc_sem and the tty_buffer lock. The first source of deadlock, the tty->ldisc_sem, can/is avoided by not waiting for the ldisc ref; ie., the buffer flush is simply not performed if the ldisc ref is not acquired. In this context, not acquiring the ldisc_sem is only possible when changing the line discipline. Although this approach is not perfect, I feel it's a > 99% solution. The second source of deadlock stems from the fact that the input worker is holding the tty buffer lock while processing input. While this prevents a concurrent buffer flush of its own tty buffer, this also threatens a lock order inversion: CPU 0 | CPU 1 flush_to_ldisc() | flush_to_ldisc() claim slave buffer lock | claim master buffer lock - process input - | - process input - n_tty_receive_signal_char | n_tty_receive_signal_char tty_driver_flush_buffer | tty_driver_flush_buffer pty_flush_buffer | pty_flush_buffer tty_buffer_flush(other) | tty_buffer_flush(other) try to claim other buf lock | try to claim other buf lock * DEADLOCK * _Except_ the CPU1 call chain is not possible because the pty master can never have termios settings of either BRKINT or ISIG, so the lock order inversion is not possible. So patch 2 re-enables the tty_buffer_flush() in pty_flush_buffer() and adds lockdep annotation for the tty buffer lock; normal ttys and pty masters use the subclass 0 lock and pty slaves use the subclass 1 lock. This will still warn of any lock order inversions that are actually a problem. Patch 1 just generalizes the existing lockdep annotation used for the tty_lock(), so that patch 2 and 3 can use it. Patch 3 fixes the very obvious problems that shows up when pty slaves start flushing data; all kinds of i/o ordering issues show up. For example, if you interrupt a 'cat large-text-file', the echoed '^C' appears out-of-order, or a chunk of output is missing before the trailing out (because that is now flushed by pty_flush_buffer() but the writer hasn't processed the signal yet). FWIW, these same problems exist with regular ttys, but the speed of ptys makes it way more obvious. Regards, Peter Hurley (3): tty: Make lock subclasses available for other tty locks pty: Fix buffer flush deadlock n_tty: Fix signal handling flushes drivers/tty/n_tty.c | 45 ++++++++++++++++++++++++++++++--------------- drivers/tty/pty.c | 11 ++++++++++- drivers/tty/tty_buffer.c | 6 ++++++ drivers/tty/tty_mutex.c | 12 +----------- include/linux/tty.h | 24 ++++++++++++++++++++++++ 5 files changed, 71 insertions(+), 27 deletions(-) -- 2.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html