linux-kernel - Re: [PATCH printk v4 07/27] printk: nbcon: Use driver synchronization while registering

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 for Android: free password hash cracker in your pocket

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

Date: Tue, 9 Apr 2024 11:46:32 +0200
From: Petr Mladek <pmladek@...e.com>
To: John Ogness <john.ogness@...utronix.de>
Cc: Sergey Senozhatsky <senozhatsky@...omium.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH printk v4 07/27] printk: nbcon: Use driver
 synchronization while registering

On Wed 2024-04-03 00:17:09, John Ogness wrote:
> Depending on if an nbcon console is registered, a driver may
> handle its internal locking differently. If a driver is holding
> its internal lock while the nbcon console is registered, there
> may be a risk that two different contexts access the hardware
> simultaneously without synchronization. (For example, if the
> printk subsystem invokes atomic printing while another driver
> context acquired the internal lock without considering the
> atomic console.)
> 
> Use the driver synchronization while a registering nbcon console
> transitions to being registered. This guarantees that if the
> driver acquires its internal lock when the nbcon console was not
> registered, it will remain unregistered until that context
> releases the lock.
> 
> Signed-off-by: John Ogness <john.ogness@...utronix.de>

Looks reasonable:

Reviewed-by: Petr Mladek <pmladek@...e.com>

Note:

The printk kthread integration is not part of this patchset.
I see in linux-rt-devel that nbcon_kthread_func() emits
a pending record under con->driver_lock(). This is
a solution to prevent a race with the driver lock.

IMHO, it is not strictly necessary to take the driver_lock()
in the kthread. Instead, it would be enough to make sure that
the kthread is running only when the device driver is properly
registered as the console driver.

Well, we should probably discuss this in the patchset introducing
the kthread.

Best Regards,
Petr