[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 13 Dec 2016 00:28:36 +0900
From: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To: Petr Mladek <pmladek@...e.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jan Kara <jack@...e.cz>, Tejun Heo <tj@...nel.org>,
Calvin Owens <calvinowens@...com>,
Thomas Gleixner <tglx@...utronix.de>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [RFC][PATCHv5 3/7] printk: introduce per-cpu safe_print seq
buffer
On (12/12/16 14:54), Petr Mladek wrote:
[..]
> > > Hmm, I wanted to describe why we need another per-CPU buffer in NMI
> > > and I am not sure that we really need it.
> >
> > NMI-printk can interrupt safe-printk's vsnprintf() in the middle of
> > the "while (*fmt)" loop: safe-priNMI-PRINTK
>
> But this already happens when any of the WARNs is triggered
> inside vsnprintf(). Either this is safe or we are in
> trouble.
[..]
> Well, I am not sure if we should bother.
well, I'd probably agree that we shouldn't care. I'd may be even
say that nested warnings from vsnprintf() are not so important to
over-complicated everything (comparing to lost NMI-printk messages,
which are really important).
> Well, is it that bad to ask for better comments?
ok, I'll take a look. gotta re-base the series once again anyway.
> Or am I dumb and it was all obvious?
of course no! I never said that. never! :)
my apologies.
-ss
Powered by blists - more mailing lists