BMC/Intel-BMC/linux.git/drivers/tty/n_tty.c, branch dev-4.3

n_tty: Fix unsafe reference to "other" ldisc

2016-02-19T22:28:34+00:00

commit 6d27a63caad3f13e96cf065d2d96828c2006be6b upstream. Although n_tty_check_unthrottle() has a valid ldisc reference (since the tty core gets the ldisc ref in tty_read() before calling the line discipline read() method), it does not have a valid ldisc reference to the "other" pty of a pty pair. Since getting an ldisc reference for tty->link essentially open-codes tty_wakeup(), just replace with the equivalent tty_wakeup(). Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

n_tty: Fix poll() after buffer-limited eof push read

2016-02-19T22:28:34+00:00

commit ac8f3bf8832a405cc6e4dccb1d26d5cb2994d234 upstream. commit 40d5e0905a03 ("n_tty: Fix EOF push handling") fixed EOF push for reads. However, that approach still allows a condition mismatch between poll() and read(), where poll() returns POLLIN but read() blocks. This state can happen when a previous read() returned because the user buffer was full and the next character was an EOF not at the beginning of the line. While the next read() will properly identify the condition and advance the read buffer tail without improperly indicating an EOF file condition (ie., read() will not mistakenly return 0), poll() will mistakenly indicate POLLIN. Although a possible solution would be to peek at the input buffer in n_tty_poll(), the better solution in this patch is to eat the EOF during the previous read() (ie., fix the problem by eliminating the condition). The current canon line buffer copy limits the scan for next end-of-line to the smaller of either, a. the remaining user buffer size b. completed lines in the input buffer When the remaining user buffer size is exactly one less than the end-of-line marked by EOF push, the EOF is not scanned nor skipped but left for subsequent reads. In the example below, the scan index 'eol' has stopped at the EOF because it is past the scan limit of 5 (not because it has found the next set bit in read_flags) user buffer [*nr = 5] _ _ _ _ _ read_flags 0 0 0 0 0 1 input buffer h e l l o [EOF] ^ ^ / / tail eol result: found = 0, tail += 5, *nr += 5 Instead, allow the scan to peek ahead 1 byte (while still limiting the scan to completed lines in the input buffer). For the example above, result: found = 1, tail += 6, *nr += 5 Because the scan limit is now bumped +1 byte, when the scan is completed, the tail advance and the user buffer copy limit is re-clamped to *nr when EOF is _not_ found. Fixes: 40d5e0905a03 ("n_tty: Fix EOF push handling") Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

tty: audit: Fix audit source

2015-12-09T19:34:42+00:00

commit 6b2a3d628aa752f0ab825fc6d4d07b09e274d1c1 upstream. The data to audit/record is in the 'from' buffer (ie., the input read buffer). Fixes: 72586c6061ab ("n_tty: Fix auditing support for cannonical mode") Cc: Miloslav Trmač Signed-off-by: Peter Hurley Acked-by: Laura Abbott Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

tty: fix stall caused by missing memory barrier in drivers/tty/n_tty.c

2015-10-04T18:03:40+00:00

My colleague ran into a program stall on a x86_64 server, where n_tty_read() was waiting for data even if there was data in the buffer in the pty. kernel stack for the stuck process looks like below. #0 [ffff88303d107b58] __schedule at ffffffff815c4b20 #1 [ffff88303d107bd0] schedule at ffffffff815c513e #2 [ffff88303d107bf0] schedule_timeout at ffffffff815c7818 #3 [ffff88303d107ca0] wait_woken at ffffffff81096bd2 #4 [ffff88303d107ce0] n_tty_read at ffffffff8136fa23 #5 [ffff88303d107dd0] tty_read at ffffffff81368013 #6 [ffff88303d107e20] __vfs_read at ffffffff811a3704 #7 [ffff88303d107ec0] vfs_read at ffffffff811a3a57 #8 [ffff88303d107f00] sys_read at ffffffff811a4306 #9 [ffff88303d107f50] entry_SYSCALL_64_fastpath at ffffffff815c86d7 There seems to be two problems causing this issue. First, in drivers/tty/n_tty.c, __receive_buf() stores the data and updates ldata->commit_head using smp_store_release() and then checks the wait queue using waitqueue_active(). However, since there is no memory barrier, __receive_buf() could return without calling wake_up_interactive_poll(), and at the same time, n_tty_read() could start to wait in wait_woken() as in the following chart. __receive_buf() n_tty_read() ------------------------------------------------------------------------ if (waitqueue_active(&tty->read_wait)) /* Memory operations issued after the RELEASE may be completed before the RELEASE operation has completed */ add_wait_queue(&tty->read_wait, &wait); ... if (!input_available_p(tty, 0)) { smp_store_release(&ldata->commit_head, ldata->read_head); ... timeout = wait_woken(&wait, TASK_INTERRUPTIBLE, timeout); ------------------------------------------------------------------------ The second problem is that n_tty_read() also lacks a memory barrier call and could also cause __receive_buf() to return without calling wake_up_interactive_poll(), and n_tty_read() to wait in wait_woken() as in the chart below. __receive_buf() n_tty_read() ------------------------------------------------------------------------ spin_lock_irqsave(&q->lock, flags); /* from add_wait_queue() */ ... if (!input_available_p(tty, 0)) { /* Memory operations issued after the RELEASE may be completed before the RELEASE operation has completed */ smp_store_release(&ldata->commit_head, ldata->read_head); if (waitqueue_active(&tty->read_wait)) __add_wait_queue(q, wait); spin_unlock_irqrestore(&q->lock,flags); /* from add_wait_queue() */ ... timeout = wait_woken(&wait, TASK_INTERRUPTIBLE, timeout); ------------------------------------------------------------------------ There are also other places in drivers/tty/n_tty.c which have similar calls to waitqueue_active(), so instead of adding many memory barrier calls, this patch simply removes the call to waitqueue_active(), leaving just wake_up*() behind. This fixes both problems because, even though the memory access before or after the spinlocks in both wake_up*() and add_wait_queue() can sneak into the critical section, it cannot go past it and the critical section assures that they will be serialized (please see "INTER-CPU ACQUIRING BARRIER EFFECTS" in Documentation/memory-barriers.txt for a better explanation). Moreover, the resulting code is much simpler. Latency measurement using a ping-pong test over a pty doesn't show any visible performance drop. Signed-off-by: Kosuke Tatsukawa Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

Merge 4.2-rc4 into tty-next

2015-07-27T18:12:39+00:00

Other serial driver work wants to build on patches now in 4.2-rc4 so merge the branch so this can properly happen. Signed-off-by: Greg Kroah-Hartman

tty: add missing rcu_read_lock for task_pgrp

2015-07-24T00:56:38+00:00

task_pgrp requires an rcu or tasklist lock to be obtained if the returned pid is to be dereferenced, which kill_pgrp does. Obtain an RCU lock for the duration of use. Signed-off-by: Patrick Donnelly Reviewed-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

n_tty: signal and flush atomically

2015-07-23T22:05:53+00:00

When handling signalling char, claim the termios write lock before signalling waiting readers and writers to prevent further i/o before flushing the echo and output buffers. This prevents a userspace signal handler which may output from racing the terminal flush. Reference: Bugzilla #99351 ("Output truncated in ssh session after...") Fixes: commit d2b6f44779d3 ("n_tty: Fix signal handling flushes") Reported-by: Filipe Brandenburger Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

Merge 4.1-rc7 into tty-next

2015-06-08T17:49:28+00:00

This fixes up a merge issue with the amba-pl011.c driver, and we want the fixes in this branch as well. Signed-off-by: Greg Kroah-Hartman

n_tty: Fix auditing support for cannonical mode

2015-05-31T22:11:04+00:00

Commit 32f13521ca68bc624ff6effc77f308a52b038bf0 ("n_tty: Line copy to user buffer in canonical mode") changed cannonical mode copying to use copy_to_user but missed adding the call to the audit framework. Add in the appropriate functions to get audit support. Fixes: 32f13521ca68 ("n_tty: Line copy to user buffer in canonical mode") Reported-by: Miloslav Trmač Signed-off-by: Laura Abbott Reviewed-by: Peter Hurley Cc: stable Signed-off-by: Greg Kroah-Hartman

n_tty: Fix calculation of size in canon_copy_from_read_buf

2015-05-24T19:43:50+00:00

There was a hardcoded value of 4096 which should have been N_TTY_BUF_SIZE. This caused reads from tty to fail with EFAULT when they shouldn't have done if N_TTY_BUF_SIZE was declared to be something other than 4096. Signed-off-by: Mark Tomlinson Reviewed-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman