linux-kernel - Re: [V4] serial: core: Do stop_rx in suspend path for console if console

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: <fb44af37-daf7-974d-95fe-1a6c2cdab676@samsung.com>
Date:   Thu, 2 Jun 2022 00:25:42 +0200
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     Vijaya Krishna Nivarthi <quic_vnivarth@...cinc.com>,
        gregkh@...uxfoundation.org, jirislaby@...nel.org,
        linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     quic_msavaliy@...cinc.com, dianders@...omium.org, mka@...omium.org,
        swboyd@...omium.org
Subject: Re: [V4] serial: core: Do stop_rx in suspend path for console if
 console_suspend is disabled

Hi,

On 01.06.2022 13:24, Vijaya Krishna Nivarthi wrote:
> On 5/24/2022 5:24 PM, Marek Szyprowski wrote:
>> On 23.05.2022 23:32, Marek Szyprowski wrote:
>>> Hi,
>>>
>>> On 16.05.2022 11:20, Vijaya Krishna Nivarthi wrote:
>>>> For the case of console_suspend disabled, if back to back 
>>>> suspend/resume
>>>> test is executed, at the end of test, sometimes console would 
>>>> appear to
>>>> be frozen not responding to input. This would happen because, during
>>>> resume, rx transactions can come in before system is ready, 
>>>> malfunction
>>>> of rx happens in turn resulting in console appearing to be stuck.
>>>>
>>>> Do a stop_rx in suspend sequence to prevent this.
>>>>
>>>> Signed-off-by: Vijaya Krishna Nivarthi <quic_vnivarth@...cinc.com>
>>>> ---
>>>> v4: moved the change to serial core to apply for all drivers
>>>> v3: swapped the order of conditions to be more human readable
>>>> v2: restricted patch to contain only stop_rx in suspend sequence
>>>> v1: intial patch contained 2 additional unrelated changes in vicinity
>>>> ---
>>> This patch landed recently in linux-next as commit c9d2325cdb92
>>> ("serial: core: Do stop_rx in suspend path for console if
>>> console_suspend is disabled").
>>>
>>> Unfortunately it breaks console operation on my test systems after
>>> system suspend/resume cycle if 'no_console_suspend' kernel parameter
>>> is present. System properly resumes from suspend, the console displays
>>> all the messages and even command line prompt, but then doesn't react
>>> on any input. If I remove the 'no_console_suspend' parameter, the
>>> console is again operational after system suspend/resume cycle. Before
>>> this patch it worked fine regardless the 'no_console_suspend' 
>>> parameter.
>>>
>>> If this matters, the test system is ARM 32bit Samsung Exynos5422-based
>>> Odroid XU3lite board.
>>
>> One more information. This issue can be easily reproduced with QEMU. It
>> happens both on ARM 32bit and ARM 64bit QEMU's 'virt' machines when
>> 'no_console_suspend' is added to kernel's cmdline.
>>
> Ideally, as comments indicate, the set_termios should have done 
> stop_rx at begin and start_rx at end to take care of this issue.
>
> This is probably missing in your driver. Can we check if this can be 
> fixed? 

Sure, just point me what need to be added in amba-pl011.c and 
samsung_tty.c. I've briefly compared the suspend/resume paths of those 
drivers with other drivers and I don't see anything missing there.

> OR other option is
>
> Add a start_rx in uart_resume_port after call to set_termios to handle 
> this scenario for other drivers.
>
> Please let me know if there are any concerns for this options.

IMHO this looks like an issue that affects lots of drivers and it should 
be handled in the core.

 > ...

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland