linux-kernel - RE: Problem with nbcon console and amba-pl011 serial port

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: <84wm9sne7w.fsf@jogness.linutronix.de>
Date: Wed, 04 Jun 2025 09:50:03 +0206
From: John Ogness <john.ogness@...utronix.de>
To: "Toshiyuki Sato (Fujitsu)" <fj6611ie@...itsu.com>
Cc: 'Michael Kelley' <mhklinux@...look.com>, "pmladek@...e.com"
 <pmladek@...e.com>, 'Ryo Takakura' <ryotkkr98@...il.com>, Russell King
 <linux@...linux.org.uk>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Jiri Slaby <jirislaby@...nel.org>, "linux-kernel@...r.kernel.org"
 <linux-kernel@...r.kernel.org>, "linux-serial@...r.kernel.org"
 <linux-serial@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>, "Toshiyuki Sato (Fujitsu)"
 <fj6611ie@...itsu.com>
Subject: RE: Problem with nbcon console and amba-pl011 serial port

On 2025-06-04, "Toshiyuki Sato (Fujitsu)" <fj6611ie@...itsu.com> wrote:
>> Unrelated to this particular report, I am looking at commit 2eb2608618ce
>> ("serial: amba-pl011: Implement nbcon console") and I do not think it
>> implements atomic printing correctly.
>> 
>> pl011_console_write_atomic() assumes uap->clk is disabled when it is
>> called. However, if it took over ownership from the printing kthread,
>> the uap->clk is already enabled. And then after printing its line it
>> disables uap->clk, even though the interrupted printing kthread expects
>> uap->clk to still be enabled once it regains ownership.
>
> I believe the Common Clock Framework manages the enable count for clocks.
> Specifically, uap->clk->core->enable_count is incremented by clk_enable
> and decremented by clk_disable.
> Wouldn't the clock remain enabled until enable_count reaches 0?

You are correct. I wasn't aware that the clock framework had a usage
counter to allow recursive calls. Sorry for the noise.

John