Messages in this thread | | | From | John Ogness <> | Subject | Re: [PATCH printk 06/18] printk: Protect [un]register_console() with a mutex | Date | Thu, 29 Sep 2022 01:48:29 +0206 |
| |
On 2022-09-27, Petr Mladek <pmladek@suse.com> wrote: > Hmm, the new mutex is really nasty. It has very strange semantic. > It makes the locking even more complicated.
We are working to replace the BKL-console_lock with new separate clearly defined mechanisms.
The new mutex provides full synchronization for list changes as well as changes to items of that list. (Really console->flags is the only change to items of the list.)
For some places in the code it is very clear that the console_lock can be completely replaced (either with srcu or the new mutex). For other places, it is not yet clear why the console_lock is being used and so both console_lock and mutex are used.
> The ideal solution would be take console_lock() here.
We should be looking where we can remove console_lock, not identifying new locations to add it.
> A good enough solution might be call this under the later added > srcu_read_lock(&console_srcu) and use for_each_console_srcu().
@console_srcu does not allow safe reading of console->flags. It only provides safe list iteration and reading of immutable fields. The new mutex must be used for reading console->flags.
Note that for the NOBKL consoles (not part of this series), a new atomic state variable is used so that console->flags is not needed. That means for NOBKL consoles the new mutex is further reduced in scope to provide only list synchronization.
> Or is this part of some strategy to remove console_sem later, please?
Yes! One of the main points of this final phase of the rework is to remove console_sem usage (for NOBKL consoles). If a system is running with only NOBKL consoles registered, ideally that system should never call console_lock()/console_trylock(). Once all drivers have converted over to the NOBKL interface, console_sem will serve no purpose for the printk and console frameworks, so it can be removed.
John
| |