summaryrefslogtreecommitdiff
path: root/mm
diff options
context:
space:
mode:
authorAlan Cox <alan@linux.intel.com>2009-07-16 15:07:03 (GMT)
committerLinus Torvalds <torvalds@linux-foundation.org>2009-07-16 16:19:16 (GMT)
commit807708844979ba8c6d5717345a8608454992696d (patch)
tree97daa91a0ddd6ed6fe48a5967762523c4fe1f924 /mm
parent9237a81a1468d0aca1cc4e244bba2362d6f81b35 (diff)
downloadlinux-807708844979ba8c6d5717345a8608454992696d.tar.xz
n_tty: Fix echo race
If a tty in N_TTY mode with echo enabled manages to get itself into a state where - echo characters are pending - FASYNC is enabled - tty_write_wakeup is called from either - a device write path (pty) - an IRQ (serial) then it either deadlocks or explodes taking a mutex in the IRQ path. On the serial side it is almost impossible to reproduce because you have to go from a full serial port to a near empty one with echo characters pending. The pty case happens to have become possible to trigger using emacs and ptys, the pty changes having created a scenario which shows up this bug. The code path is n_tty:process_echoes() (takes mutex) tty_io:tty_put_char() pty:pty_write (or serial paths) tty_wakeup (from pty_write or serial IRQ) n_tty_write_wakeup() process_echoes() *KABOOM* Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions