linux-kernel - Re: [PATCHv2-next 2/3] serial/sysrq: Add MAGIC_SYSRQ_SERIAL

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a8d1a5df-8c72-049f-3bb4-5fae0166d760@arista.com>
Date:   Tue, 14 Jan 2020 17:36:59 +0000
From:   Dmitry Safonov <dima@...sta.com>
To:     Joe Perches <joe@...ches.com>, linux-kernel@...r.kernel.org
Cc:     Dmitry Safonov <0x7f454c46@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Iurii Zaikin <yzaikin@...gle.com>,
        Jiri Slaby <jslaby@...e.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Vasiliy Khoruzhick <vasilykh@...sta.com>,
        linux-serial@...r.kernel.org
Subject: Re: [PATCHv2-next 2/3] serial/sysrq: Add MAGIC_SYSRQ_SERIAL_SEQUENCE

Hi Joe,

On 1/14/20 5:30 PM, Joe Perches wrote:
> On Tue, 2020-01-14 at 17:19 +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.
> 
> Hi again Dmitry.  trivia:
> 
>> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> []
>> +/**
>> + *	uart_try_toggle_sysrq - Enables SysRq from serial line
>> + *	@port: uart_port structure where char(s) after BREAK met
>> + *	@ch: new character in the sequence after received BREAK
>> + *
>> + *	Enables magic SysRq when the required sequence is met on port
>> + *	(see CONFIG_MAGIC_SYSRQ_SERIAL_SEQUENCE).
>> + *
>> + *	Returns 0 if @ch is out of enabling sequence and should be
>> + *	handled some other way, 1 if @ch was consumed.
>> + */
> 
> Normally bool functions return values are true/false not 1/0.

I agree. Though, somehow it seems to me that `return 1` is a bit closer
to "one character consumed" than "return true".
Again, no hard feelings, just a preference.
I can change those returns to bools if you insist :)

> 
>> +static bool uart_try_toggle_sysrq(struct uart_port *port, unsigned int ch)
>> +{
>> +	if (ARRAY_SIZE(sysrq_toggle_seq) <= 1)
>> +		return 0;
> 
> 		return false;
> 
> etc...
> 
> 

Thanks,
          Dmitry