[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac094aa6-3b8d-6a96-b635-0634052bf3cf@i-love.sakura.ne.jp>
Date: Tue, 10 Jul 2018 20:55:41 +0900
From: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To: Josh Poimboeuf <jpoimboe@...hat.com>,
Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...nel.org>, mingo@...hat.com,
linux-kernel@...r.kernel.org,
Andy Lutomirski <luto@...capital.net>,
Borislav Petkov <bp@...e.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] x86: Avoid pr_cont() in show_opcodes()
On 2018/07/10 4:11, Josh Poimboeuf wrote:
> On Mon, Jul 09, 2018 at 10:49:53AM +0200, Peter Zijlstra wrote:
>> 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().
>>
>> But how big of a problem is that really? We can't very well remove all
>> pr_cont stuff from the kernel.
>
> I'd say we should try to make oopses as legible as possible.
>
> Also KERN_CONT is inherently broken, and we should avoid using it in
> general, IMO.
>
We can't afford removing all pr_cont()/KERN_CONT.
But show_opcodes() is an example of function which is expected to be SMP-safe.
/*
* Annotation for a "continued" line of log printout (only done after a
* line that had no enclosing \n). Only to be used by core/arch code
* during early bootup (a continued line is not SMP-safe otherwise).
*/
#define KERN_CONT KERN_SOH "c"
Powered by blists - more mailing lists