linux-stable.git/drivers/tty, branch v4.1.6 Linux kernel stable tree n_tty: signal and flush atomically 2015-08-10T19:21:57+00:00 Peter Hurley peter@hurleysoftware.com 2015-06-27T13:21:32+00:00 ba3961ad681981dc74fcd519b8f98be8bc3ac381 commit 3b19e032295647b7be2aa3be62510db4aaeda759 upstream. 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 <filbranden@google.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 3b19e032295647b7be2aa3be62510db4aaeda759 upstream.

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 <filbranden@google.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: core: Fix crashes while echoing when closing 2015-08-10T19:21:56+00:00 Peter Hurley peter@hurleysoftware.com 2015-07-13T01:05:26+00:00 df86527517e8cd14f7ebec7302e70590543a49b5 commit e144c58cad6667876173dd76977e9e6557e34941 upstream. While closing, new rx data may be received after the input buffers have been flushed but before stop_rx() halts receiving [1]. The new data might not be processed by flush_to_ldisc() until after uart_shutdown() and normal input processing is re-enabled (ie., tty->closing = 0). The race is outlined below: CPU 0 | CPU 1 | uart_close() | tty_port_close_start() | tty->closing = 1 | tty_ldisc_flush() | | => IRQ | while (LSR & data ready) | uart_insert_char() | tty_flip_buffer_push() | <= EOI stop_rx() | . uart_shutdown() | . free xmit.buf | . tty_port_tty_set(NULL) | . tty->closing = 0 | . | flush_to_ldisc() | n_tty_receive_buf_common() | __receive_buf() | ... | commit_echoes() | uart_flush_chars() | __uart_start() | ** OOPS on port.tty deref ** tty_ldisc_flush() | Input processing must be prevented from echoing (tty->closing = 1) until _after_ the input buffers have been flushed again at the end of uart_close(). [1] In fact, some input may actually be buffered _after_ stop_rx() since the rx interrupt may have already triggered but not yet been handled when stop_rx() disables rx interrupts. Fixes: 2e758910832d ("serial: core: Flush ldisc after dropping port mutex in uart_close()") Reported-by: Robert Elliott <elliott@hp.com> Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit e144c58cad6667876173dd76977e9e6557e34941 upstream.

While closing, new rx data may be received after the input buffers
have been flushed but before stop_rx() halts receiving [1]. The
new data might not be processed by flush_to_ldisc() until after
uart_shutdown() and normal input processing is re-enabled (ie.,
tty->closing = 0). The race is outlined below:

CPU 0                         | CPU 1
                              |
uart_close()                  |
   tty_port_close_start()     |
      tty->closing = 1        |
      tty_ldisc_flush()       |
                              | => IRQ
                              |   while (LSR & data ready)
                              |      uart_insert_char()
                              |   tty_flip_buffer_push()
                              | <= EOI
   stop_rx()                  |   .
   uart_shutdown()            |   .
      free xmit.buf           |   .
   tty_port_tty_set(NULL)     |   .
   tty->closing = 0           |   .
                              | flush_to_ldisc()
                              |   n_tty_receive_buf_common()
                              |      __receive_buf()
                              |         ...
                              |         commit_echoes()
                              |            uart_flush_chars()
                              |               __uart_start()
                              | ** OOPS on port.tty deref **
   tty_ldisc_flush()          |

Input processing must be prevented from echoing (tty->closing = 1)
until _after_ the input buffers have been flushed again at the end
of uart_close().

[1] In fact, some input may actually be buffered _after_ stop_rx()
since the rx interrupt may have already triggered but not yet been
handled when stop_rx() disables rx interrupts.

Fixes: 2e758910832d ("serial: core: Flush ldisc after dropping port
mutex in uart_close()")
Reported-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "serial: imx: initialized DMA w/o HW flow enabled" 2015-08-10T19:21:56+00:00 David Jander david@protonic.nl 2015-06-26T06:11:30+00:00 4eede03b97bf6d89681905668e983f99b5847827 commit 907eda32a36fcdb979bdb91ea097abb3dd2c23c9 upstream. This reverts commit 068500e08dc87ea9a453cc4a500cf3ab28d0f936. According to some tests, SDMA support is broken at least for i.MX6 without HW flow control. Different forms of data-corruption appear either with the ROM firmware for the SDMA controller as well as when loading Freescale provided SDMA firmware versions 1.1 or 3.1. Signed-off-by: David Jander <david@protonic.nl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 907eda32a36fcdb979bdb91ea097abb3dd2c23c9 upstream.

This reverts commit 068500e08dc87ea9a453cc4a500cf3ab28d0f936.

According to some tests, SDMA support is broken at least for i.MX6 without
HW flow control. Different forms of data-corruption appear either with
the ROM firmware for the SDMA controller as well as when loading Freescale
provided SDMA firmware versions 1.1 or 3.1.

Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty: remove platform_sysrq_reset_seq 2015-08-03T16:29:15+00:00 Arnd Bergmann arnd@arndb.de 2015-05-26T21:45:29+00:00 0bcd77743dd60a8a64a9a39e25007968f8cc1c37 commit ffb6e0c9a0572f8e5f8e9337a1b40ac2ec1493a1 upstream. The platform_sysrq_reset_seq code was intended as a way for an embedded platform to provide its own sysrq sequence at compile time. After over two years, nobody has started using it in an upstream kernel, and the platforms that were interested in it have moved on to devicetree, which can be used to configure the sequence without requiring kernel changes. The method is also incompatible with the way that most architectures build support for multiple platforms into a single kernel. Now the code is producing warnings when built with gcc-5.1: drivers/tty/sysrq.c: In function 'sysrq_init': drivers/tty/sysrq.c:959:33: warning: array subscript is above array bounds [-Warray-bounds] key = platform_sysrq_reset_seq[i]; We could fix this, but it seems unlikely that it will ever be used, so let's just remove the code instead. We still have the option to pass the sequence either in DT, using the kernel command line, or using the /sys/module/sysrq/parameters/reset_seq file. Fixes: 154b7a489a ("Input: sysrq - allow specifying alternate reset sequence") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ffb6e0c9a0572f8e5f8e9337a1b40ac2ec1493a1 upstream.

The platform_sysrq_reset_seq code was intended as a way for an embedded
platform to provide its own sysrq sequence at compile time. After over two
years, nobody has started using it in an upstream kernel, and the platforms
that were interested in it have moved on to devicetree, which can be used
to configure the sequence without requiring kernel changes. The method is
also incompatible with the way that most architectures build support for
multiple platforms into a single kernel.

Now the code is producing warnings when built with gcc-5.1:

drivers/tty/sysrq.c: In function 'sysrq_init':
drivers/tty/sysrq.c:959:33: warning: array subscript is above array bounds [-Warray-bounds]
   key = platform_sysrq_reset_seq[i];

We could fix this, but it seems unlikely that it will ever be used, so
let's just remove the code instead. We still have the option to pass the
sequence either in DT, using the kernel command line, or using the
/sys/module/sysrq/parameters/reset_seq file.

Fixes: 154b7a489a ("Input: sysrq - allow specifying alternate reset sequence")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: samsung: only use earlycon for console 2015-08-03T16:29:15+00:00 Arnd Bergmann arnd@arndb.de 2015-05-19T20:26:04+00:00 06ab12e64f674aedd402505e2ad89b1765cc86e0 commit 357d56151976a78d90dc3dfac01777de0ef05212 upstream. A configuration that enables earlycon but not the core console code causes a link error: drivers/built-in.o: In function `setup_earlycon': drivers/tty/serial/earlycon.c:70: undefined reference to `uart_parse_earlycon' That error can be triggered by the newly added samsung earlycon support, which is missing a 'select' statement. As suggested by Peter Hurley, solves the problem by moving the 'select SERIAL_EARLYCON' statement to the samsung console driver option, as it is done by all other console drivers. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: b94ba0328d3b3 ("serial: samsung: Add support for early console") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 357d56151976a78d90dc3dfac01777de0ef05212 upstream.

A configuration that enables earlycon but not the core console
code causes a link error:

  drivers/built-in.o: In function `setup_earlycon':
  drivers/tty/serial/earlycon.c:70: undefined reference to `uart_parse_earlycon'

That error can be triggered by the newly added samsung earlycon support,
which is missing a 'select' statement.

As suggested by Peter Hurley, solves the problem by moving the
'select SERIAL_EARLYCON' statement to the samsung console driver
option, as it is done by all other console drivers.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: b94ba0328d3b3 ("serial: samsung: Add support for early console")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty/serial: at91: RS485 mode: 0 is valid for delay_rts_after_send 2015-08-03T16:29:07+00:00 Nicolas Ferre nicolas.ferre@atmel.com 2015-05-11T11:00:31+00:00 6e853d1593afa65bcddaa991b1b4fef508262317 commit 8687634b7908c42eb700e0469e110e02833611d1 upstream. In RS485 mode, we may want to set the delay_rts_after_send value to 0. In the datasheet, the 0 value is said to "disable" the Transmitter Timeguard but this is exactly the expected behavior if we want no delay... Moreover, if the value was set to non-zero value by device-tree or earlier ioctl command, it was impossible to change it back to zero. Reported-by: Sami Pietikäinen <Sami.Pietikainen@wapice.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 8687634b7908c42eb700e0469e110e02833611d1 upstream.

In RS485 mode, we may want to set the delay_rts_after_send value to 0.
In the datasheet, the 0 value is said to "disable" the Transmitter Timeguard but
this is exactly the expected behavior if we want no delay...

Moreover, if the value was set to non-zero value by device-tree or earlier
ioctl command, it was impossible to change it back to zero.

Reported-by: Sami Pietikäinen <Sami.Pietikainen@wapice.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'tty-4.1-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty 2015-06-07T05:14:23+00:00 Linus Torvalds torvalds@linux-foundation.org 2015-06-07T05:14:23+00:00 b334b77351890a137f31a38f1ca2f1de0886a453 Pull tty/serial driver fixes from Greg KH: "Here are a few TTY and Serial driver fixes for reported regressions and crashes. All of these have been in linux-next with no reported problems" * tag 'tty-4.1-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: n_tty: Fix auditing support for cannonical mode serial: 8250_omap: provide complete custom startup & shutdown callbacks n_tty: Fix calculation of size in canon_copy_from_read_buf serial: imx: Fix DMA handling for IDLE condition aborts serial/amba-pl011: Unconditionally poll for FIFO space before each TX char 
Pull tty/serial driver fixes from Greg KH:
 "Here are a few TTY and Serial driver fixes for reported regressions
  and crashes.

  All of these have been in linux-next with no reported problems"

* tag 'tty-4.1-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  n_tty: Fix auditing support for cannonical mode
  serial: 8250_omap: provide complete custom startup & shutdown callbacks
  n_tty: Fix calculation of size in canon_copy_from_read_buf
  serial: imx: Fix DMA handling for IDLE condition aborts
  serial/amba-pl011: Unconditionally poll for FIFO space before each TX char
n_tty: Fix auditing support for cannonical mode 2015-05-31T22:11:04+00:00 Laura Abbott labbott@fedoraproject.org 2015-05-14T18:42:17+00:00 72586c6061ab8c23ffd9f301ed19782a44ff5f04 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č <mitr@redhat.com> Signed-off-by: Laura Abbott <labbott@fedoraproject.org> Reviewed-by: Peter Hurley <peter@hurleysoftware.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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č <mitr@redhat.com>
Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: 8250_omap: provide complete custom startup & shutdown callbacks 2015-05-31T22:10:37+00:00 Sebastian Andrzej Siewior bigeasy@linutronix.de 2015-05-20T20:07:35+00:00 9809889c708ebffe240608eef39b667082f2c945 The currently in-use port->startup and port->shutdown are "okay". The startup part for instance does the tiny omap extra part and invokes serial8250_do_startup() for the remaining pieces. The workflow in serial8250_do_startup() is okay except for the part where UART_RX is read without a check if there is something to read. I tried to workaround it in commit 0aa525d11859 ("tty: serial: 8250_core: read only RX if there is something in the FIFO") but then reverted it later in commit ca8bb4aefb9 ("serial: 8250: Revert "tty: serial: 8250_core: read only RX if there is something in the FIFO""). This is the second attempt to get it to work on older OMAPs without breaking other chips this time Peter Hurley suggested to pull in the few needed lines from serial8250_do_startup() and drop everything else that is not required including making it simpler like using just request_irq() instead the chain handler like it is doing now. So lets try that. Fixes: ca8bb4aefb93 ("serial: 8250: Revert "tty: serial: 8250_core: read only RX if there is something in the FIFO"") Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The currently in-use port->startup and port->shutdown are "okay". The
startup part for instance does the tiny omap extra part and invokes
serial8250_do_startup() for the remaining pieces. The workflow in
serial8250_do_startup() is okay except for the part where UART_RX is
read without a check if there is something to read. I tried to
workaround it in commit 0aa525d11859 ("tty: serial: 8250_core: read only
RX if there is something in the FIFO") but then reverted it later in
commit ca8bb4aefb9 ("serial: 8250: Revert "tty: serial: 8250_core: read
only RX if there is something in the FIFO"").

This is the second attempt to get it to work on older OMAPs without
breaking other chips this time
Peter Hurley suggested to pull in the few needed lines from
serial8250_do_startup() and drop everything else that is not required
including making it simpler like using just request_irq() instead the
chain handler like it is doing now.
So lets try that.

Fixes: ca8bb4aefb93 ("serial: 8250: Revert "tty: serial: 8250_core:
       read only RX if there is something in the FIFO"")
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ttyFDC: Fix to use native endian MMIO reads 2015-05-26T14:46:52+00:00 James Hogan james.hogan@imgtec.com 2015-04-28T09:57:30+00:00 70f041b6e1ff508750988ffd034ac6117d34d4d7 The MIPS Common Device Memory Map (CDMM) is internal to the core and has native endianness. There is therefore no need to byte swap the accesses on big endian targets, so convert the Fast Debug Channel (FDC) TTY driver to use __raw_readl()/__raw_writel() rather than ioread32()/iowrite32(). Fixes: 4cebec609aea ("TTY: Add MIPS EJTAG Fast Debug Channel TTY driver") Fixes: c2d7ef51d731 ("ttyFDC: Implement KGDB IO operations.") Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Jiri Slaby <jslaby@suse.cz> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/9905/ Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ralf Baechle <ralf@linux-mips.org> 
The MIPS Common Device Memory Map (CDMM) is internal to the core and has
native endianness. There is therefore no need to byte swap the accesses
on big endian targets, so convert the Fast Debug Channel (FDC) TTY
driver to use __raw_readl()/__raw_writel() rather than
ioread32()/iowrite32().

Fixes: 4cebec609aea ("TTY: Add MIPS EJTAG Fast Debug Channel TTY driver")
Fixes: c2d7ef51d731 ("ttyFDC: Implement KGDB IO operations.")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9905/
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>