Messages in this thread | | | Date | Wed, 30 May 2018 19:00:37 +0900 | From | Sergey Senozhatsky <> | Subject | Re: [PATCH] printk: drop in_nmi check from printk_safe_flush_on_panic() |
| |
On (05/30/18 18:55), Sergey Senozhatsky wrote: > > > > I understand why you came with it but I am against this change without > > a proper research. This would redirect too valuable messages into > > a buffer of a limited size and postpone flushing them to the consoles. > > > > We would need to really carefully compare chances where this would > > help and where it would make things worse. There is a high chance > > that we could come with a better solution once we have the analyze. > > I agree, sure. > > 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.
-ss
| |