linux-stable.git/drivers/tty/serial/serial_core.c, branch linux-5.7.y

serial: core: fix sysrq overhead regression

2020-07-22T07:34:20+00:00

commit 08d5470308ac3598e7709d08b8979ce6e9de8da2 upstream.

Commit 8e20fc391711 ("serial_core: Move sysrq functions from header
file") converted the inline sysrq helpers to exported functions which
are now called for every received character, interrupt and break signal
also on systems without CONFIG_MAGIC_SYSRQ_SERIAL instead of being
optimised away by the compiler.

Inlining these helpers again also avoids the function call overhead when
CONFIG_MAGIC_SYSRQ_SERIAL is enabled (e.g. when the port is not used as
a console).

Fixes: 8e20fc391711 ("serial_core: Move sysrq functions from header file")
Cc: Dmitry Safonov <0x7f454c46@gmail.com>
Signed-off-by: Johan Hovold 
Cc: stable 
Reviewed-by: Andy Shevchenko 
Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com>
Link: https://lore.kernel.org/r/20200610152232.16925-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman

Revert "serial: core: Refactor uart_unlock_and_check_sysrq()"

2020-07-22T07:34:20+00:00

commit 10652a9e9fe3fbcaca090f99cd3060ac3fee2913 upstream.

This reverts commit da9a5aa3402db0ff3b57216d8dbf2478e1046cae.

In order to ease backporting a fix for a sysrq regression, revert this
rewrite which was since added on top.

The other sysrq helpers now bail out early when sysrq is not enabled;
it's better to keep that pattern here as well.

Note that the __releases() attribute won't be needed after the follow-on
fix either.

Fixes: da9a5aa3402d ("serial: core: Refactor uart_unlock_and_check_sysrq()")
Cc: stable 
Signed-off-by: Johan Hovold 
Reviewed-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200610152232.16925-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman

serial: core: Initialise spin lock before use in uart_configure_port()

2020-07-22T07:34:08+00:00

[ Upstream commit f743061a85f5e9989df22ccbf07c80c98fc90e08 ]

The comment near to uart_port_spin_lock_init() says:

  Ensure that the serial console lock is initialised early.
  If this port is a console, then the spinlock is already initialised.

and there is nothing about enabled or disabled consoles. The commit
a3cb39d258ef ("serial: core: Allow detach and attach serial device
for console") made a change, which follows the comment, and also to
prevent reinitialisation of the lock in use, when user detaches and
attaches back the same console device. But this change discovers
another issue, that uart_add_one_port() tries to access a spin lock
that now may be uninitialised. This happens when a driver expects
the serial core to register a console on its behalf. In this case
we must initialise a spin lock before use.

Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console")
Reported-by: Marc Zyngier 
Reported-by: Lad Prabhakar 
Reported-by: Guenter Roeck 
Reported-by: Anatoly Pugachev 
Acked-by: Marc Zyngier 
Tested-by: Tony Lindgren 
Cc: Geert Uytterhoeven 
Signed-off-by: Andy Shevchenko 
Tested-by: Lad Prabhakar 
Link: https://lore.kernel.org/r/20200706214903.56148-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

serial: core: Allow detach and attach serial device for console

2020-03-17T14:57:59+00:00

In the future we would like to disable power management on the serial devices
used as kernel consoles to avoid weird behaviour in some cases. However,
disabling PM may prevent system to go to deep sleep states, which in its turn
leads to the higher power consumption.

Tony Lindgren proposed a work around, i.e. allow user to detach such consoles
to make PM working again. In case user wants to see what's going on, it also
provides a mechanism to attach console back.

Link: https://lists.openwall.net/linux-kernel/2018/09/29/65
Suggested-by: Tony Lindgren 
Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200217114016.49856-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

serial: core: Refactor uart_unlock_and_check_sysrq()

2020-03-12T16:16:42+00:00

Refactor uart_unlock_and_check_sysrq() to:

  - explicitly show that we release a port lock which makes
    static analyzers happy:

CHECK   drivers/tty/serial/serial_core.c
.../serial_core.c:3290:17: warning: context imbalance in 'uart_unlock_and_check_sysrq' - unexpected unlock

  - use flags instead of irqflags to avoid confusion with IRQ flags

  - provide one return point

  - be more compact

Signed-off-by: Andy Shevchenko 
Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com>
Link: https://lore.kernel.org/r/20200310174337.74109-4-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

serial: core: Use uart_console() helper in SysRq code

2020-03-12T16:16:41+00:00

Use uart_console() helper in SysRq code instead of open coded variant.
This eliminates the conditional entirely for SERIAL_CORE_CONSOLE=n case.
While here, refactor the conditional to be more compact.

Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com>
Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200310174337.74109-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

serial: core: Print escaped SysRq Magic sequence if enabled

2020-03-12T16:16:41+00:00

It is useful to see on the serial console the magic sequence itself
to enable SysRq without rummaging source code.

Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com>
Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200310174337.74109-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

serial: core: Use string length for SysRq magic sequence

2020-03-12T16:16:41+00:00

Compiler is not happy about using ARRAY_SIZE() in comparison to smaller type:

  CC      drivers/tty/serial/serial_core.o
.../serial_core.c: In function ‘uart_try_toggle_sysrq’:
.../serial_core.c:3222:24: warning: comparison is always false due to limited range of data type [-Wtype-limits]
 3222 |  if (++port->sysrq_seq < (ARRAY_SIZE(sysrq_toggle_seq) - 1)) {
      |                        ^

Looking at the code it appears that there is an additional weirdness,
i.e. use ARRAY_SIZE() against simple string literal. Yes, the idea probably
was to allow '\0' in the sequence, but it's impractical: kernel configuration
won't accept it to begin with followed by a comment about '\0' before
comparison in question.

Drop all these by switching to strlen() and convert code accordingly.

Note, GCC seems clever enough to calculate string length at compile time.

Fixes: 68af43173d3f ("serial/sysrq: Add MAGIC_SYSRQ_SERIAL_SEQUENCE")
Reviewed-by: Dmitry Safonov <0x7f454c46@gmail.com>
Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200310174337.74109-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman

serial/sysrq: Add MAGIC_SYSRQ_SERIAL_SEQUENCE

2020-03-07T08:52:02+00:00

Many embedded boards have a disconnected TTL level serial which can
generate some garbage that can lead to spurious false sysrq detects.

Currently, sysrq can be either completely disabled for serial console
or always disabled (with CONFIG_MAGIC_SYSRQ_SERIAL), since
commit 732dbf3a6104 ("serial: do not accept sysrq characters via serial port")

At Arista, we have such boards that can generate BREAK and random
garbage. While disabling sysrq for serial console would solve
the problem with spurious false sysrq triggers, it's also desirable
to have a way to enable sysrq back.

As a measure of balance between on and off options, add
MAGIC_SYSRQ_SERIAL_SEQUENCE which is a string sequence that can enable
sysrq if it follows BREAK on a serial line. The longer the string - the
less likely it may be in the garbage.

Having the way to enable sysrq was beneficial to debug lockups with
a manual investigation in field and on the other side preventing false
sysrq detections.

Based-on-patch-by: Vasiliy Khoruzhick 
Signed-off-by: Dmitry Safonov 
Link: https://lore.kernel.org/r/20200302175135.269397-3-dima@arista.com
Signed-off-by: Greg Kroah-Hartman

serial: core: Switch to use DEVICE_ATTR_RO()

2020-02-17T16:01:54+00:00

Move device attributes to DEVICE_ATTR_RO() as that would make things
a lot more "obvious" what is happening here.

Suggested-by: Greg Kroah-Hartman 
Signed-off-by: Andy Shevchenko 
Link: https://lore.kernel.org/r/20200217114016.49856-2-andriy.shevchenko@linux.intel.com
Signed-off-by: Greg Kroah-Hartman