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 -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
