[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f3b0dee2b61940b5976571e769692ec9@AcuMS.aculab.com>
Date: Mon, 9 Jul 2018 13:22:39 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Peter Zijlstra' <peterz@...radead.org>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
CC: Ingo Molnar <mingo@...nel.org>,
"mingo@...hat.com" <mingo@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Tetsuo Handa <penguin-kernel@...ove.SKAURA.ne.jp>,
Andy Lutomirski <luto@...capital.net>,
Borislav Petkov <bp@...e.de>,
Josh Poimboeuf <jpoimboe@...hat.com>,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: RE: [PATCH] x86: Avoid pr_cont() in show_opcodes()
From: Peter Zijlstra
> Sent: 09 July 2018 09:50
> On Sat, Jul 07, 2018 at 10:54:28PM +0900, Tetsuo Handa wrote:
> > >> Since syzbot is confused by concurrent printk() messages [1],
> > >> this patch changes show_opcodes() to use snprintf().
snprintf() is probably the wrong function.
You want the variant that always returns the number of characters
added to the buffer - not the number that would have been added
were the buffer infinite length.
> But how big of a problem is that really? We can't very well remove all
> pr_cont stuff from the kernel.
On my ubuntu 17.10 system with a 4.13 kernel some messages printed with
pr_cont end up split when displayed by dmesg.
(These are from one of our drivers, I've not looked very hard at it though.)
So maybe removing pr_cont isn't a bad idea.
David
Powered by blists - more mailing lists