Messages in this thread | | | From | John Ogness <> | Subject | Re: port lock: was: Re: [PATCH printk v1 11/18] printk: nobkl: Introduce printer threads | Date | Thu, 20 Apr 2023 12:39:31 +0206 |
| |
On 2023-04-20, Petr Mladek <pmladek@suse.com> wrote: >> OK, let's first define what the two locks are supposed to synchronize. >> My understanding is that this patchset uses them the following way: >> >> + The new lock (atomic_state) is used to serialize emiting >> messages between different write contexts. It replaces >> the functionality of console_lock.
It replaces the functionality of console_lock, but operates at a finer level. It is serializing all access to the hardware registers involved in outputting. For the 8250 driver, this is the IER register.
>> It is a per-console sleeping lock, allows voluntary and has >> hand-over using priorities and spinning with a timeout.
It is not a sleeping lock. It is used as a trylock or spinning with timeout. It has the special feature that it can be handed over to or stolen by another context with a higher ownership priority.
>> + The port_lock is used to synchronize various operations >> of the console driver/device, like probe, init, exit, >> configuration update. >> >> It is typically a per-console driver/device spin lock. >> >> >> I guess that we would want to keep both locks:
I agree because the port_lock has a much larger scope and is fully preemptible under PREEMPT_RT.
> I forgot to check how these two locks are supposed to be used > in write_atomic(). > > It seems that cons_atomic_flush_con() takes only the new lock > (atomic_state) and ignores the port_lock(). It should be safe > against write_kthread(). But it is not safe against other > operations with the console device that are synchronized > only by the port_lock().
Yes, it is because the console drivers will also take the atomic_state lock when needed. You can see this in the POC patch I posted [0].
For example, a new function serial8250_enter_unsafe() is used by the serial drivers to mark the beginning of an unsafe section. To use this function, the port_lock must be held. This function additionally takes the atomic_state lock. Then the driver is allowed to touch hardware registers related to outputting (IER).
But typically the driver will use a new higher level function, for example serial8250_in_IER(), which will enter unsafe, read the register, and exit unsafe. This provides the necessary synchronization against write_atomic() (for the 8250 driver).
Please also remember that hostile takeovers of drivers in unsafe sections are done as a last resort in panic, after all other nbcon consoles have safely flushed their buffers. So we should not spend too many brain cycles on "what if the atomic_state lock is stolen while in an unsafe section" questions. The answer is: then you are in "hope and pray" mode.
John
[0] https://lore.kernel.org/lkml/877cv1geo4.fsf@jogness.linutronix.de
| |