summaryrefslogtreecommitdiffstats
path: root/drivers/tty/pty.c
diff options
context:
space:
mode:
authorEvan Green <evgreen@chromium.org>2018-05-09 13:44:29 -0700
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2018-05-14 13:52:35 +0200
commit638a6f4ebeba82ad098fdfa4449011074d3e2673 (patch)
tree5b66fed0f99c6b2f179baea060eb4e79e311c084 /drivers/tty/pty.c
parentd76c74387e1c978b6c5524a146ab0f3f72206f98 (diff)
downloadlinux-638a6f4ebeba82ad098fdfa4449011074d3e2673.tar.bz2
tty: serial: msm_geni_serial: Fix TX infinite loop
The GENI serial driver handled transmit by leaving stuff in the common circular buffer until it had completely caught up to the head, then clearing it out all at once. This is a suboptimal way to do transmit, as it leaves data in the circular buffer that could be freed. Moreover, the logic implementing it is wrong, and it is easy to get into a situation where the UART infinitely writes out the same buffer. I could reproduce infinite serial output of the same buffer by running dmesg, then hitting Ctrl-C. I believe what happened is xmit_size was something large, marching towards a larger value. Then the generic OS code flushed out the buffer and replaced it with two characters. Now the xmit_size is a large value marching towards a small value, which it wasn't expecting. The driver subtracts xmit_size (very large) from uart_circ_chars_pending (2), underflows, and repeats ad nauseum. The locking isn't wrong here, as the locks are held whenever the buffer is manipulated, it's just that the driver wasn't expecting the buffer to be flushed out from underneath it in between transmits. This change reworks transmit to grab what it can from the circular buffer, and then update ->tail, both fixing the underflow and freeing up space for a smoother circular experience. Signed-off-by: Evan Green <evgreen@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'drivers/tty/pty.c')
0 files changed, 0 insertions, 0 deletions