linux/drivers/tty, branch v4.3

Revert "serial: 8250_dma: don't bother DMA with small transfers"

2015-10-18T04:24:46Z

This reverts commit 9119fba0cfeda6d415c9f068df66838a104b87cb. This commit prevents from sending "big" file using Bluetooth. When sending a lot of data quickly through the Bluetooth interface, and after a variable amount of data sent, transfer fails with error: kernel: [ 415.247453] Bluetooth: hci0 hardware error 0x00 Found on T100TA. After reverting this commit, send works fine for any file size. Signed-off-by: Frederic Danis Fixes: 9119fba0cfed (serial: 8250_dma: don't bother DMA with small transfers) Cc: stable@vger.kernel.org Reviewed-by: Heikki Krogerus Acked-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman

drivers/tty: require read access for controlling terminal

2015-10-04T18:20:30Z

This is mostly a hardening fix, given that write-only access to other users' ttys is usually only given through setgid tty executables. Signed-off-by: Jann Horn Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

serial: 8250: add uart_config entry for PORT_RT2880

2015-10-04T18:16:12Z

This adds an entry to the uart_config table for PORT_RT2880 enabling rx/tx FIFOs. The UART is actually a Palmchip BK-3103 which is found in several devices from Alchemy/RMI, Ralink, and Sigma Designs. Signed-off-by: Mans Rullgard Cc: stable Signed-off-by: Greg Kroah-Hartman

tty: fix data race on tty_buffer.commit

2015-10-04T18:03:40Z

Race on buffer data happens when newly committed data is picked up by an old flush work in the following scenario: __tty_buffer_request_room does a plain write of tail->commit, no barriers were executed before that. At this point flush_to_ldisc reads this new value of commit, and reads buffer data, no barriers in between. The committed buffer data is not necessary visible to flush_to_ldisc. Similar bug happens when tty_schedule_flip commits data. Update commit with smp_store_release and read commit with smp_load_acquire, as it is commit that signals data readiness. This is orthogonal to the existing synchronization on tty_buffer.next, which is required to not dismiss a buffer with unconsumed data. The data race was found with KernelThreadSanitizer (KTSAN). Signed-off-by: Dmitry Vyukov Reviewed-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

tty: fix data race in tty_buffer_flush

2015-10-04T18:03:40Z

tty_buffer_flush frees not acquired buffers. As the result, for example, read of b->size in tty_buffer_free can return garbage value which will lead to a huge buffer hanging in the freelist. This is just the benignest manifestation of freeing of a not acquired object. If the object is passed to kfree, heap can be corrupted. Acquire visibility over the buffer before freeing it. The data race was found with KernelThreadSanitizer (KTSAN). Signed-off-by: Dmitry Vyukov Reviewed-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

tty: fix data race in flush_to_ldisc

2015-10-04T18:03:40Z

flush_to_ldisc reads port->itty and checks that it is not NULL, concurrently release_tty sets port->itty to NULL. It is possible that flush_to_ldisc loads port->itty once, ensures that it is not NULL, but then reloads it again and uses. The second load can already return NULL, which will cause a crash. Use READ_ONCE to read port->itty. The data race was found with KernelThreadSanitizer (KTSAN). Signed-off-by: Dmitry Vyukov Reviewed-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman

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

2015-10-04T18:03:40Z

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

serial: atmel: fix error path of probe function

2015-10-04T17:51:42Z

If atmel_init_gpios fails the port has already been marked as busy (in line 2629), so this must be undone in the error path. This bug was introduced because I created the patch that finally became 722ccf416ac2 ("serial: atmel: fix error handling when mctrl_gpio_init fails") on top of 3.19 which didn't have commit 6fbb9bdf0f3f ("tty/serial: at91: fix error handling in atmel_serial_probe()") yet. Signed-off-by: Uwe Kleine-König Fixes: 722ccf416ac2 ("serial: atmel: fix error handling when mctrl_gpio_init fails") Acked-by: Nicolas Ferre Signed-off-by: Greg Kroah-Hartman

tty: don't leak cdev in tty_cdev_add()

2015-10-04T17:51:42Z

Commit a3a10ce3429e ("Avoid usb reset crashes by making tty_io cdevs truly dynamic") which mixes using cdev_alloc() and cdev_init() is problematic. Subsequent call to cdev_init() after cdev_alloc() sets kobj release method from cdev_dynamic_release() to cdev_default_release() and thus makes it impossible to free allocated cdev. This patch also consolidates error path of cdev_add() as cdev can also leak here if things went wrong. Signed-off-by: Leon Yu Fixes: a3a10ce3429e ("Avoid usb reset crashes by making tty_io cdevs truly dynamic") Acked-by: Richard Watts Signed-off-by: Greg Kroah-Hartman

Revert "serial: imx: remove unbalanced clk_prepare"

2015-10-04T17:51:42Z

This reverts commit 9e7b399d6528eac33a6fbfceb2b92af209c3454d. Commit ("9e7b399d6528ea") causes the following warning and sometimes also hangs the system: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at kernel/locking/mutex.c:868 mutex_trylock+0x20c/0x22c() DEBUG_LOCKS_WARN_ON(in_interrupt()) Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc7-next-20150818-00001-g14418a6 #4 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) Backtrace: [<80012f08>] (dump_backtrace) from [<800130a4>] (show_stack+0x18/0x1c) r6:00000364 r5:00000000 r4:00000000 r3:00000000 [<8001308c>] (show_stack) from [<807902b8>] (dump_stack+0x88/0xa4) [<80790230>] (dump_stack) from [<8002a604>] (warn_slowpath_common+0x80/0xbc) r5:807945c4 r4:80ab3b50 [<8002a584>] (warn_slowpath_common) from [<8002a6e4>] (warn_slowpath_fmt+0x38/0x40) r8:00000000 r7:8131100c r6:8054c3cc r5:8131300c r4:80b0a570 [<8002a6b0>] (warn_slowpath_fmt) from [<807945c4>] (mutex_trylock+0x20c/0x22c) r3:8095d0d8 r2:8095ab28 [<807943b8>] (mutex_trylock) from [<8054c3cc>] (clk_prepare_lock+0x14/0xf4) r7:8131100c r6:be3f0c80 r5:00000037 r4:be3f0c80 [<8054c3b8>] (clk_prepare_lock) from [<8054dbfc>] (clk_prepare+0x18/0x30) r5:00000037 r4:be3f0c80 [<8054dbe4>] (clk_prepare) from [<8036a600>] (imx_console_write+0x30/0x244) r4:812d0bc8 r3:8132b9a4 To reproduce the problem we only need to let the board idle for something like 30 seconds. Tested on a imx6q-sabresd. Signed-off-by: Fabio Estevam Reviewed-by: Eduardo Valentin Signed-off-by: Greg Kroah-Hartman