linux.git/drivers/tty, branch v4.17.1

tty: Use __GFP_NOFAIL for tty_ldisc_get()

2018-04-25T13:03:44+00:00

syzbot is reporting crashes triggered by memory allocation fault injection
at tty_ldisc_get() [1]. As an attempt to handle OOM in a graceful way, we
have tried commit 5362544bebe85071 ("tty: don't panic on OOM in
tty_set_ldisc()"). But we reverted that attempt by commit a8983d01f9b7d600
("Revert "tty: don't panic on OOM in tty_set_ldisc()"") due to reproducible
crash. We should spend resource for finding and fixing race condition bugs
rather than complicate error paths for 2 * sizeof(void *) bytes allocation
failure.

[1] https://syzkaller.appspot.com/bug?id=489d33fa386453859ead58ff5171d43772b13aa3

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Cc: Michal Hocko 
Cc: Vegard Nossum 
Cc: Dmitry Vyukov 
Cc: Jiri Slaby 
Cc: Peter Hurley 
Cc: One Thousand Gnomes 
Cc: Linus Torvalds 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

tty: serial: xuartps: Setup early console when uartclk is also passed

2018-04-23T09:12:22+00:00

Baudrate calculation depends on requested baudrate and uart clock.
This patch is checking that uartclk is also passed.

The same logic is used 8250_early.c/init_port function.

Signed-off-by: Michal Simek 
Signed-off-by: Greg Kroah-Hartman

tty: Don't call panic() at tty_ldisc_init()

2018-04-23T09:05:52+00:00

syzbot is reporting kernel panic [1] triggered by memory allocation failure
at tty_ldisc_get() from tty_ldisc_init(). But since both tty_ldisc_get()
and caller of tty_ldisc_init() can cleanly handle errors, tty_ldisc_init()
does not need to call panic() when tty_ldisc_get() failed.

[1] https://syzkaller.appspot.com/bug?id=883431818e036ae6a9981156a64b821110f39187

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

tty: Avoid possible error pointer dereference at tty_ldisc_restore().

2018-04-23T09:05:52+00:00

syzbot is reporting crashes [1] triggered by memory allocation failure at
tty_ldisc_get() from tty_ldisc_restore(). While syzbot stops at WARN_ON()
due to panic_on_warn == true, panic_on_warn == false will after all trigger
an OOPS by dereferencing old->ops->num if IS_ERR(old) == true.

We can simplify tty_ldisc_restore() as three calls (old->ops->num, N_TTY,
N_NULL) to tty_ldisc_failto() in addition to avoiding possible error
pointer dereference.

If someone reports kernel panic triggered by forcing all memory allocations
for tty_ldisc_restore() to fail, we can consider adding __GFP_NOFAIL for
tty_ldisc_restore() case.

[1] https://syzkaller.appspot.com/bug?id=6ac359c61e71d22e06db7f8f88243feb11d927e7

Reported-by: syzbot+40b7287c2dc987c48c81@syzkaller.appspotmail.com
Signed-off-by: Tetsuo Handa 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
Cc: Dmitry Vyukov 
Cc: Johannes Weiner 
Cc: Alan Cox 
Cc: Christoph Hellwig 
Cc: Michal Hocko 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

tty: serial: qcom_geni_serial: Use signed variable to get IRQ

2018-04-23T08:22:30+00:00

The platform_get_irq can return error. Assigning the return value to an
unsigned variable and checking it for negative value will always return
false.

Use an intermediate signed variable to get IRQ information, check for any
error and then assign it to 'irq' variable inside uart_port structure.

Signed-off-by: Karthikeyan Ramasubramanian 
Reported-by: Dan Carpenter 
Reviewed-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

earlycon: Use a pointer table to fix __earlycon_table stride

2018-04-23T08:06:59+00:00

Commit 99492c39f39f ("earlycon: Fix __earlycon_table stride") tried to fix
__earlycon_table stride by forcing the earlycon_id struct alignment to 32
and asking the linker to 32-byte align the __earlycon_table symbol.  This
fix was based on commit 07fca0e57fca92 ("tracing: Properly align linker
defined symbols") which tried a similar fix for the tracing subsystem.

However, this fix doesn't quite work because there is no guarantee that
gcc will place structures packed into an array format.  In fact, gcc 4.9
chooses to 64-byte align these structs by inserting additional padding
between the entries because it has no clue that they are supposed to be in
an array.  If we are unlucky, the linker will assign symbol
"__earlycon_table" to a 32-byte aligned address which does not correspond
to the 64-byte aligned contents of section "__earlycon_table".

To address this same problem, the fix to the tracing system was
subsequently re-implemented using a more robust table of pointers approach
by commits:
 3d56e331b653 ("tracing: Replace syscall_meta_data struct array with pointer array")
 654986462939 ("tracepoints: Fix section alignment using pointer array")
 e4a9ea5ee7c8 ("tracing: Replace trace_event struct array with pointer array")

Let's use this same "array of pointers to structs" approach for
EARLYCON_TABLE.

Fixes: 99492c39f39f ("earlycon: Fix __earlycon_table stride")
Signed-off-by: Daniel Kurtz 
Suggested-by: Aaron Durbin 
Reviewed-by: Rob Herring 
Tested-by: Guenter Roeck 
Reviewed-by: Guenter Roeck 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman

serial: imx: fix cached UCR2 read on software reset

2018-04-23T07:53:36+00:00

To reset the UART the SRST needs be cleared (low active). According
to the documentation the bit will remain active for 4 module clocks
until it is cleared (set to 1).

Hence the real register need to be read in case the cached register
indicates that the SRST bit is zero.

This bug lead to wrong baudrate because the baud rate register got
restored before reset completed in imx_flush_buffer.

Fixes: 3a0ab62f43de ("serial: imx: implement shadow registers for UCRx and UFCR")
Signed-off-by: Stefan Agner 
Reviewed-by: Fabio Estevam 
Reviewed-by: Uwe Kleine-König 
Signed-off-by: Greg Kroah-Hartman

serial: imx: warn user when using unsupported configuration

2018-04-23T07:53:36+00:00

When using half-duplex mode (which disables receiver during txing)
the RTS signal cannot be driven low during transmission when using
i.MX UART RTS/CTS control. This seems to be a limitation of the
i.MX UART IP: The RTS (CTS_B) signal is controlled by the receiver.
When the receiver is disabled, the signal stays in UART logic idle
state which is high...

If SER_RS485_RTS_ON_SEND is used, RTS needs to be high active during
transmission. Since this is the default state of the RTS (CTS_B)
signal when the receiver is off, half-duplex mode in this
configuration works fine.

However, a low-active RTS signal (flag SER_RS485_RTS_ON_SEND not set)
cannot be generated when the receiver is turned off.

Print an error if the user selects this unsupported configuration
(both SER_RS485_RTS_ON_SEND and SER_RS485_RX_DURING_TX unset) and
configure the closest working configuration (set the
SER_RS485_RX_DURING_TX flag).

Signed-off-by: Stefan Agner 
Acked-by: Uwe Kleine-König 
Signed-off-by: Greg Kroah-Hartman

serial: mvebu-uart: Fix local flags handling on termios update

2018-04-22T15:35:31+00:00

Commit 68a0db1d7da2 reworked the baud rate selection, but also added
a (not so) subtle change in the way the local flags (c_lflag in the
termios structure) are handled, forcing the new flags to always be the
same as the old ones.

The reason for that particular change is both obscure and undocumented.
It also completely breaks userspace. Something as trivial as getty is
unusable:


	Debian GNU/Linux 9 sy-borg ttyMV0

	sy-borg login: root
	root
	[timeout]

	Debian GNU/Linux 9 sy-borg ttyMV0


which is quite obvious in retrospect: getty cannot get in control of
the echo mode, is stuck in canonical mode, and times out without ever
seeing anything valid. It also begs the question of how this change was
ever tested.

The fix is pretty obvious: stop messing with c_lflag, and the world
will be a happier place.

Cc: stable@vger.kernel.org # 4.15+
Fixes: 68a0db1d7da2 ("serial: mvebu-uart: add function to change baudrate")
Signed-off-by: Marc Zyngier 
Signed-off-by: Greg Kroah-Hartman

tty: n_gsm: Fix DLCI handling for ADM mode if debug & 2 is not set

2018-04-22T15:34:40+00:00

At least on droid 4 with control channel in ADM mode, there is no response
to Modem Status Command (MSC). Currently gsmtty_modem_update() expects to
have data in dlci->modem_rx unless debug & 2 is set. This means that on
droid 4, things only work if debug & 2 is set.

Let's fix the issue by ignoring empty dlci->modem_rx for ADM mode. In
the AMD mode, CMD_MSC will never respond and gsm_process_modem() won't
get called to set dlci->modem_rx.

And according to ts_127010v140000p.pdf, MSC is only relevant if basic
option is chosen, so let's test for that too.

Fixes: ea3d8465ab9b ("tty: n_gsm: Allow ADM response in addition to UA for control dlci")
Cc: linux-serial@vger.kernel.org
Cc: Alan Cox 
Cc: Dan Williams 
Cc: Jiri Prchal 
Cc: Jiri Slaby 
Cc: Marcel Partap 
Cc: Merlijn Wajer 
Cc: Michael Nazzareno Trimarchi 
Cc: Michael Scott 
Cc: Pavel Machek 
Cc: Peter Hurley 
Cc: Russ Gorby 
Cc: Sascha Hauer 
Cc: Sebastian Reichel 
Signed-off-by: Tony Lindgren 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman