Messages in this thread | | | Date | Tue, 4 Oct 2022 09:28:53 +0200 | From | Petr Mladek <> | Subject | Re: [PATCH printk 06/18] printk: Protect [un]register_console() with a mutex |
| |
On Mon 2022-10-03 21:41:22, John Ogness wrote: > On 2022-10-03, Petr Mladek <pmladek@suse.com> wrote: > > What is exactly wrong with console_lock, please? > > It is ambiguously performing multiple tasks: > > - protecting the console list > - protecting individual console fields > - serializing console printing > - stopping all console printing > > And the answer to that is: A BKL is preventing us from optimizing the > kernel by decoupling unrelated activities. > > > The above proposal suggests that it might be something like: > > > > register_console() > > { > > console_list_lock(); > > > > if (!need_console()) > > goto out; > > > > if (!try_enable_console()) > > goto out; > > > > if (!(con->flags & CON_NOBLK)) > > console_lock() > > Why are you taking the console_lock here? The console_list_lock needs to > replace this responsibility. I realize the RFC and this v1 series does > not do this. For v2, it will be clear.
This is the important information that I missed. It is a great idea. I agree that console_list_lock() would be a step forward if this worked.
As you say, in the RFC and this v1, console_lock() was still used to synchronize the list and the metadata manipulation. It means that console_lock() was as complex as before. In fact, it was even more complex because console_list_lock() appeared in its lock dependency chains. And it was not clear that v2 would be any different in this regard.
Best Regards, Petr
| |