Messages in this thread | | | From | John Ogness <> | Subject | Re: [PATCH printk 06/18] printk: Protect [un]register_console() with a mutex | Date | Fri, 30 Sep 2022 22:32:32 +0206 |
| |
On 2022-09-30, Petr Mladek <pmladek@suse.com> wrote: > You want to get cosole_lock() out of the way of NOBKL consoles. What > does it exactly mean, please?
It means that a system with only NOBKL consoles will never take the console_lock.
> What code paths are important to achieve this?
Anything that iterates or queries the consoles is taking the console_lock right now. We want that code to use something else for those tasks (console_srcu, console_mutex, atomic_state).
> From my POV, the most important code path is the kthread. But > it should use SRCU. I mean that the kthread will take neither > cosnole_lock() nor console_list_lock().
All iterators and querying are important because they need a safe interface that does not rely on console_lock.
> Is there any other code path where console_list_lock() will help > you to get console_lock() out of the way?
The difficulty arises because we are trying to share as much code as possible. So, for example, NOBKL consoles are sitting on the same list as legacy consoles. And since currently the list is protected by the console_lock, we need to change how that list is protected.
> From my POV, both locks serialize the same things > (console_list manipulation).
My v2 will hopefully change your POV. I will make it clear (in comments and implementation) that the console_lock does _not_ protect the console list. All iteration and querying will have no choice but to use the new mechanisms for list iteration and checking/setting CON_ENABLED.
Then the console_lock's only function is to block legacy consoles from printing and making sure that multiple legacy consoles are not printing in parallel. And, of course, it will still function as a general BKL lock for fbdev, which may be relying on its locking function to synchronize some fbdev data.
Note that the end result will be no change in behavior for legacy consoles. But it allows legacy and NOBKL consoles to run simultaneously while sharing significant amounts of code, and provides a clear path for console drivers to begin converting. As a side-effect, the first step of reducing the scope of the console_lock will have been taken.
John
| |