All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Dmitry Safonov <dima@arista.com>
Cc: linux-kernel@vger.kernel.org,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	Jiri Slaby <jslaby@suse.com>,
	Vasiliy Khoruzhick <vasilykh@arista.com>,
	linux-serial@vger.kernel.org
Subject: Re: [PATCH-next 3/3] serial/sysrq: Add MAGIC_SYSRQ_SERIAL_SEQUENCE
Date: Fri, 10 Jan 2020 17:46:43 +0100	[thread overview]
Message-ID: <20200110164643.GB1822445@kroah.com> (raw)
In-Reply-To: <20200109215444.95995-4-dima@arista.com>

On Thu, Jan 09, 2020 at 09:54:44PM +0000, Dmitry Safonov wrote:
> 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 <vasilykh@arista.com>
> Signed-off-by: Dmitry Safonov <dima@arista.com>
> ---
>  drivers/tty/serial/serial_core.c | 52 ++++++++++++++++++++++++++++----
>  include/linux/serial_core.h      |  2 +-
>  lib/Kconfig.debug                |  8 +++++
>  3 files changed, 55 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 6ac9dfed3423..f70eba032d0b 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -3081,6 +3081,38 @@ void uart_insert_char(struct uart_port *port, unsigned int status,
>  }
>  EXPORT_SYMBOL_GPL(uart_insert_char);
>  
> +const char sysrq_toggle_seq[] = CONFIG_MAGIC_SYSRQ_SERIAL_SEQUENCE;
> +
> +static void uart_sysrq_on(struct work_struct *w)
> +{
> +	sysrq_toggle_support(1);
> +	pr_info("SysRq is enabled by magic sequience on serial\n");

Do we want to say what serial port it is enabled on?

And why is this done in a workqueue?

> +}
> +static DECLARE_WORK(sysrq_enable_work, uart_sysrq_on);
> +
> +static int uart_try_toggle_sysrq(struct uart_port *port, unsigned int ch)
> +{
> +	if (sysrq_toggle_seq[0] == '\0')
> +		return 0;

Is constantly checking the data stream like this going to slow things
down overall?  Ah, we are just checking this after BREAK, right?  So
that hopefully will not be that bad...

> +
> +	BUILD_BUG_ON(ARRAY_SIZE(sysrq_toggle_seq) >= sizeof(port->sysrq_seq)*U8_MAX);
> +	if (sysrq_toggle_seq[port->sysrq_seq] != ch) {
> +		port->sysrq_seq = 0;
> +		return 0;
> +	}
> +
> +	/* Without the last \0 */
> +	if (++port->sysrq_seq < (ARRAY_SIZE(sysrq_toggle_seq) - 1)) {
> +		port->sysrq = jiffies + HZ*5;

5 second delay?  You should document what this value is for somewhere
here...

> +		return 1;
> +	}
> +
> +	schedule_work(&sysrq_enable_work);
> +
> +	port->sysrq = 0;
> +	return 1;
> +}
> +
>  int uart_handle_sysrq_char(struct uart_port *port, unsigned int ch)
>  {
>  	if (!IS_ENABLED(CONFIG_MAGIC_SYSRQ_SERIAL))
> @@ -3090,9 +3122,13 @@ int uart_handle_sysrq_char(struct uart_port *port, unsigned int ch)
>  		return 0;
>  
>  	if (ch && time_before(jiffies, port->sysrq)) {
> -		handle_sysrq(ch);
> -		port->sysrq = 0;
> -		return 1;
> +		if (sysrq_get_mask()) {
> +			handle_sysrq(ch);
> +			port->sysrq = 0;
> +			return 1;
> +		}

Isn't this change to test for sysrq_get_mask() a different change than
checking for the "magic" data stream?

> +		if (uart_try_toggle_sysrq(port, ch))
> +			return 1;
>  	}
>  	port->sysrq = 0;
>  
> @@ -3109,9 +3145,13 @@ int uart_prepare_sysrq_char(struct uart_port *port, unsigned int ch)
>  		return 0;
>  
>  	if (ch && time_before(jiffies, port->sysrq)) {
> -		port->sysrq_ch = ch;
> -		port->sysrq = 0;
> -		return 1;
> +		if (sysrq_get_mask()) {
> +			port->sysrq_ch = ch;
> +			port->sysrq = 0;
> +			return 1;
> +		}
> +		if (uart_try_toggle_sysrq(port, ch))
> +			return 1;
>  	}
>  	port->sysrq = 0;
>  
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index 255e86a474e9..1f4443db5474 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -243,10 +243,10 @@ struct uart_port {
>  	unsigned long		sysrq;			/* sysrq timeout */
>  	unsigned int		sysrq_ch;		/* char for sysrq */
>  	unsigned char		has_sysrq;
> +	unsigned char		sysrq_seq;		/* index in sysrq_toggle_seq */
>  
>  	unsigned char		hub6;			/* this should be in the 8250 driver */
>  	unsigned char		suspended;
> -	unsigned char		unused;

This is an unrelated change, let's leave it for a different patch that
cleans up the layout of this structure, ok?

thanks,

greg k-h

  parent reply	other threads:[~2020-01-10 16:46 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09 21:54 [PATCH-next 0/3] serial/sysrq: Add MAGIC_SYSRQ_SERIAL_SEQUENCE Dmitry Safonov
2020-01-09 21:54 ` [PATCH-next 1/3] serial_core: Move sysrq functions from header file Dmitry Safonov
2020-01-10 16:50   ` Greg Kroah-Hartman
2020-01-09 21:54 ` [PATCH-next 2/3] sysctl/sysrq: Remove __sysrq_enabled copy Dmitry Safonov
2020-01-10  3:19   ` Iurii Zaikin
2020-01-10 21:48     ` Dmitry Safonov
2020-01-10 16:40   ` Greg Kroah-Hartman
2020-01-10 21:45     ` Dmitry Safonov
2020-01-10 22:01       ` Greg Kroah-Hartman
2020-01-09 21:54 ` [PATCH-next 3/3] serial/sysrq: Add MAGIC_SYSRQ_SERIAL_SEQUENCE Dmitry Safonov
2020-01-09 23:53   ` Randy Dunlap
2020-01-10 22:02     ` Dmitry Safonov
2020-01-10 16:46   ` Greg Kroah-Hartman [this message]
2020-01-10 22:32     ` Dmitry Safonov
2020-01-14 19:10       ` Dmitry Safonov
2020-01-15 12:42         ` Greg Kroah-Hartman
2020-01-10 16:50   ` Joe Perches
2020-01-10 22:10     ` Dmitry Safonov
2020-01-11 14:08       ` Joe Perches
2020-01-10 19:01   ` kbuild test robot
2020-01-10 19:01     ` kbuild test robot
2020-01-10 19:20   ` kbuild test robot
2020-01-10 19:20     ` kbuild test robot
2020-01-11 10:52   ` kbuild test robot
2020-01-11 10:52     ` kbuild test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200110164643.GB1822445@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=0x7f454c46@gmail.com \
    --cc=dima@arista.com \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=vasilykh@arista.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.