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@linutronix.de>
---
 kernel/printk/printk.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index b7e52b3f3e96..cd32648372a0 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -3448,6 +3448,7 @@ void register_console(struct console *newcon)
 	struct console *con;
 	bool bootcon_registered = false;
 	bool realcon_registered = false;
+	unsigned long flags;
 	int err;
 
 	console_list_lock();
@@ -3539,6 +3540,19 @@ void register_console(struct console *newcon)
 		newcon->seq = 0;
 	}
 
+	/*
+	 * If another context is actively using the hardware of this new
+	 * console, it will not be aware of the nbcon synchronization. This
+	 * is a risk that two contexts could access the hardware
+	 * simultaneously if this new console is used for atomic printing
+	 * and the other context is still using the hardware.
+	 *
+	 * Use the driver synchronization to ensure that the hardware is not
+	 * in use while this new console transitions to being registered.
+	 */
+	if ((newcon->flags & CON_NBCON) && newcon->write_atomic)
+		newcon->device_lock(newcon, &flags);
+
 	/*
 	 * Put this console in the list - keep the
 	 * preferred driver at the head of the list.
@@ -3563,6 +3577,10 @@ void register_console(struct console *newcon)
 	 * register_console() completes.
 	 */
 
+	/* This new console is now registered. */
+	if ((newcon->flags & CON_NBCON) && newcon->write_atomic)
+		newcon->device_unlock(newcon, flags);
+
 	console_sysfs_notify();
 
 	/*
-- 
2.39.2

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@linutronix.de>

Looks reasonable:

Reviewed-by: Petr Mladek <pmladek@suse.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