linux-kernel - Re: printk: what is going on with additional newlines?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1504027992.2040.30.camel@perches.com>
Date:   Tue, 29 Aug 2017 10:33:12 -0700
From:   Joe Perches <joe@...ches.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Pavel Machek <pavel@....cz>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Petr Mladek <pmladek@...e.com>,
        Steven Rostedt <rostedt@...dmis.org>, Jan Kara <jack@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jiri Slaby <jslaby@...e.com>, Andreas Mohr <andi@...as.de>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: printk: what is going on with additional newlines?

On Tue, 2017-08-29 at 10:20 -0700, Linus Torvalds wrote:
> On Tue, Aug 29, 2017 at 10:10 AM, Joe Perches <joe@...ches.com> wrote:
> > That's simply false.
> > 
> > It was never true until you made it a requirement.
> > (it's not a bad requirement, but it did change behavior)
> 
> Oh, it changed behavior, yes (and for kernel code we do that, and
> require people to change).
> 
> But even before it was technically required, it was very much supposed
> to be there as a marker. KERN_CONT has existed for about a decade.

Which is very much not "forever" in kernel terms.

> It was added in commit 474925277671 ("printk: add KERN_CONT
> annotation") back in 2007, with a comment that said - at that time:

Yeah, I remember things too.

>   /*
>    * 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).
>    */

And note the "core/arch code during bootup" bit.

Look, it's not fundamentally a "bad" requirement.
It was just not "always required".

And silently slipping in the change because you
were unhappy with adding newlines to some printks
was, at best, poor form.

Your change broke a bunch of output.