Messages in this thread | | | Date | Fri, 15 Jun 2018 17:38:04 +0900 | From | Sergey Senozhatsky <> | Subject | Re: possible deadlock in console_unlock |
| |
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
| |