Messages in this thread | | | Date | Thu, 31 May 2018 16:21:00 +0200 | From | Petr Mladek <> | Subject | Re: [PATCH] printk: drop in_nmi check from printk_safe_flush_on_panic() |
| |
On Wed 2018-05-30 19:00:37, Sergey Senozhatsky wrote: > On (05/30/18 18:55), Sergey Senozhatsky wrote: > > The thing is, we, in fact, already invoke panic() in printk_safe mode. > > Sometimes. > > > > Namely, > > > > nmi_panic() -> panic() > > > > is invoked while we are in printk_nmi(), so all printk()-s go > > to the per-CPU buffers. So, at least to some extent, panic() > > in printk_safe context is not something never seen before. Just > > saying. > > Well, we have a PRINTK_NMI_DEFERRED_CONTEXT_MASK mode for > printk_nmi(). May be we can [if need be] come up with the same trick > for printk_safe_panic() mode. If logbuf spin_lock is unlocked, then > we use the main logbuf, if it is locked, we redirect printk to per-CPU > buffers and then flush it via printk_safe_flush_on_panic(), which will > re-init (unlock) the logbuf.
All these checks are racy. Now, I believe that it might really prevent a deadlock in some situations but it might also cause loosing messages in other situations (never flushed buffer). I am sorry but I am still unable to decide if it is worth the risk.
I would want to keep it as is until anyone comes with a more detailed analyze or until we get some bug reports.
Best Regards, Petr
| |