linux-toradex.git/drivers/tty, branch v4.4.93

tty: goldfish: Fix a parameter of a call to free_irq

2017-10-08T08:14:17+00:00

[ Upstream commit 1a5c2d1de7d35f5eb9793266237903348989502b ]

'request_irq()' and 'free_irq()' should be called with the same dev_id.

Signed-off-by: Christophe JAILLET 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

tty: fix __tty_insert_flip_char regression

2017-09-27T09:00:13+00:00

commit 8a5a90a2a477b86a3dc2eaa5a706db9bfdd647ca upstream.

Sergey noticed a small but fatal mistake in __tty_insert_flip_char,
leading to an oops in an interrupt handler when using any serial
port.

The problem is that I accidentally took the tty_buffer pointer
before calling __tty_buffer_request_room(), which replaces the
buffer. This moves the pointer lookup to the right place after
allocating the new buffer space.

Fixes: 979990c62848 ("tty: improve tty_insert_flip_char() fast path")
Reported-by: Sergey Senozhatsky 
Tested-by: Sergey Senozhatsky 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

tty: improve tty_insert_flip_char() slow path

2017-09-27T09:00:13+00:00

commit 065ea0a7afd64d6cf3464bdd1d8cd227527e2045 upstream.

While working on improving the fast path of tty_insert_flip_char(),
I noticed that by calling tty_buffer_request_room(), we needlessly
move to the separate flag buffer mode for the tty, even when all
characters use TTY_NORMAL as the flag.

This changes the code to call __tty_buffer_request_room() with the
correct flag, which will then allocate a regular buffer when it rounds
out of space but no special flags have been used. I'm guessing that
this is the behavior that Peter Hurley intended when he introduced
the compacted flip buffers.

Fixes: acc0f67f307f ("tty: Halve flip buffer GFP_ATOMIC memory consumption")
Cc: Peter Hurley 
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

tty: improve tty_insert_flip_char() fast path

2017-09-27T09:00:13+00:00

commit 979990c6284814617d8f2179d197f72ff62b5d85 upstream.

kernelci.org reports a crazy stack usage for the VT code when CONFIG_KASAN
is enabled:

drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

The problem is that tty_insert_flip_char() gets inlined many times into
kbd_keycode(), and also into other functions, and each copy requires 128
bytes for stack redzone to check for a possible out-of-bounds access on
the 'ch' and 'flags' arguments that are passed into
tty_insert_flip_string_flags as a variable-length string.

This introduces a new __tty_insert_flip_char() function for the slow
path, which receives the two arguments by value. This completely avoids
the problem and the stack usage goes back down to around 100 bytes.

Without KASAN, this is also slightly better, as we don't have to
spill the arguments to the stack but can simply pass 'ch' and 'flag'
in registers, saving a few bytes in .text for each call site.

This should be backported to linux-4.0 or later, which first introduced
the stack sanitizer in the kernel.

Fixes: c420f167db8c ("kasan: enable stack instrumentation")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

vt: fix unchecked __put_user() in tioclinux ioctls

2017-07-21T05:44:57+00:00

commit 6987dc8a70976561d22450b5858fc9767788cc1c upstream.

Only read access is checked before this call.

Actually, at the moment this is not an issue, as every in-tree arch does
the same manual checks for VERIFY_READ vs VERIFY_WRITE, relying on the MMU
to tell them apart, but this wasn't the case in the past and may happen
again on some odd arch in the future.

If anyone cares about 3.7 and earlier, this is a security hole (untested)
on real 80386 CPUs.

Signed-off-by: Adam Borowski 
Signed-off-by: Greg Kroah-Hartman

serial: efm32: Fix parity management in 'efm32_uart_console_get_options()'

2017-06-26T05:13:09+00:00

commit be40597a1bc173bf9dadccdf5388b956f620ae8f upstream.

UARTn_FRAME_PARITY_ODD is 0x0300
UARTn_FRAME_PARITY_EVEN is 0x0200
So if the UART is configured for EVEN parity, it would be reported as ODD.
Fix it by correctly testing if the 2 bits are set.

Fixes: 3afbd89c9639 ("serial/efm32: add new driver")
Signed-off-by: Christophe JAILLET 
Acked-by: Uwe Kleine-König 
Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Fix panic when serial console and DMA are enabled

2017-06-14T11:16:26+00:00

commit 3c9101766b502a0163d1d437fada5801cf616be2 upstream.

This patch fixes an issue that kernel panic happens when DMA is enabled
and we press enter key while the kernel booting on the serial console.

* An interrupt may occur after sci_request_irq().
* DMA transfer area is initialized by setup_timer() in sci_request_dma()
  and used in interrupt.

If an interrupt occurred between sci_request_irq() and setup_timer() in
sci_request_dma(), DMA transfer area has not been initialized yet.
So, this patch changes the order of sci_request_irq() and
sci_request_dma().

Fixes: 73a19e4c0301 ("serial: sh-sci: Add DMA support.")
Signed-off-by: Takatoshi Akiyama 
[Shimoda changes the commit log]
Signed-off-by: Yoshihiro Shimoda 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

tty: Drop krefs for interrupted tty lock

2017-06-14T11:16:26+00:00

commit e9036d0662360cd4c79578565ce422ed5872f301 upstream.

When the tty lock is interrupted on attempted re-open, 2 tty krefs
are still held. Drop extra kref before returning failure from
tty_lock_interruptible(), and drop lookup kref before returning
failure from tty_open().

Fixes: 0bfd464d3fdd ("tty: Wait interruptibly for tty lock on reopen")
Reported-by: Dmitry Vyukov 
Signed-off-by: Peter Hurley 
Cc: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

serial: ifx6x60: fix use-after-free on module unload

2017-06-14T11:16:20+00:00

commit 1e948479b3d63e3ac0ecca13cbf4921c7d17c168 upstream.

Make sure to deregister the SPI driver before releasing the tty driver
to avoid use-after-free in the SPI remove callback where the tty
devices are deregistered.

Fixes: 72d4724ea54c ("serial: ifx6x60: Add modem power off function in the platform reboot process")
Cc: Jun Chen 
Signed-off-by: Johan Hovold 
Signed-off-by: Greg Kroah-Hartman

tty: pty: Fix ldisc flush after userspace become aware of the data already

2017-05-20T12:27:02+00:00

commit 77dae6134440420bac334581a3ccee94cee1c054 upstream.

While using emacs, cat or others' commands in konsole with recent
kernels, I have met many times that CTRL-C freeze konsole. After
konsole freeze I can't type anything, then I have to open a new one,
it is very annoying.

See bug report:
https://bugs.kde.org/show_bug.cgi?id=175283

The platform in that bug report is Solaris, but now the pty in linux
has the same problem or the same behavior as Solaris :)

It has high possibility to trigger the problem follow steps below:
Note: In my test, BigFile is a text file whose size is bigger than 1G
1:open konsole
1:cat BigFile
2:CTRL-C

After some digging, I find out the reason is that commit 1d1d14da12e7
("pty: Fix buffer flush deadlock") changes the behavior of pty_flush_buffer.

Thread A                                 Thread B
--------                                 --------
1:n_tty_poll return POLLIN
                                         2:CTRL-C trigger pty_flush_buffer
                                             tty_buffer_flush
                                               n_tty_flush_buffer
3:attempt to check count of chars:
  ioctl(fd, TIOCINQ, &available)
  available is equal to 0

4:read(fd, buffer, avaiable)
  return 0

5:konsole close fd

Yes, I know we could use the same patch included in the BUG report as
a workaround for linux platform too. But I think the data in ldisc is
belong to application of another side, we shouldn't clear it when we
want to flush write buffer of this side in pty_flush_buffer. So I think
it is better to disable ldisc flush in pty_flush_buffer, because its new
hehavior bring no benefit except that it mess up the behavior between
POLLIN, and TIOCINQ or FIONREAD.

Also I find no flush_buffer function in others' tty driver has the
same behavior as current pty_flush_buffer.

Fixes: 1d1d14da12e7 ("pty: Fix buffer flush deadlock")
Signed-off-by: Wang YanQing 
Signed-off-by: Greg Kroah-Hartman