Re: possible deadlock in console_unlock

[Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>]

On (06/08/18 10:18), Petr Mladek wrote:
[..]
> > Could be.
> > The good thing about printk_safe is that printk_safe sections can nest.
> > I suspect there might be locks/printk_safe sections nesting at some
> > point. In any case, switching to a new flavor of printk_safe will be
> > pretty easy - just replace printk_safe_enter() with printk_foo_enter()
> > and the same for printk_save_exit().
> 
> We could allow nesting. It is just a matter of how many bits we
> reserve for it in printk_context variable.
[..]
> In each case, I would like to keep the printk_safe context usage
> at minimum. It has its own problems caused by limited per-cpu buffers
> and the need to flush them.

May be. Every new printk_safe flavour comes with increasing memory
usage. We already have a bunch of pages pinned [and mostly unused]
to every CPU for printk_nmi and printk_safe. I'm a little unsure if
we have enough reasons to pin yet another bunch of pages to every
CPU. After all printk_safe is not used very commonly, so all in all
I think we should be fine with printk_safe buffers for the time being.
We always can introduce new printk_safe mode later.

> It is basically needed only to prevent deadlocks related to logbuf_lock.

I wouldn't say that we need printk_safe for logbuf_lock only.
printk_safe helps us to avoid deadlocks on:

- logbuf_lock spin_lock
- console_sem ->lock spin_lock
- console_owner spin_lock
- scheduler ->pi_lock spin_lock
- and probably something else.

	-ss