linux-kernel - Re: [GIT PULL] trivial for 4.9

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]

Date:   Fri, 7 Oct 2016 16:36:47 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Tony Luck <tony.luck@...il.com>
Cc:     Joe Perches <joe@...ches.com>, Jiri Kosina <jikos@...nel.org>,
        Colin Ian King <colin.king@...onical.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] trivial for 4.9

On Fri, Oct 7, 2016 at 4:09 PM, Tony Luck <tony.luck@...il.com> wrote:
> On Fri, Oct 7, 2016 at 4:01 PM, Tony Luck <tony.luck@...il.com> wrote:
>> What if there isn't a "next printk" call for hours, or days?
>>
>> That poor little message without a "\n" will sit in the kernel buffers,
>> and the user who might want to see the message can't, until some
>> unrelated thing happens to print something.
>
> Retracted ...  I'm sure that at some point in the past it happened
> like that ...  but I just retested on 4.8 and the first message (with
> no "\n") showed up on the serial port just fine without some other
> message to push it out.  When the next message came along, a "\n" was
> auto-inserted.

Yeah, that immediate printout has actually always worked fine - the
newline was never really a buffering thing.

The buffering actually came fairly late, with the "newfangled"
record-oriented logging facility (4+ years old by now).

Our kernel message log was historically just a plain buffer, and not
record-oriented at all. You'd just read and write it as a stream. In
that historical context, it made tons of sense to just write something
without a newline, and then continue writing on the same line: that's
how <stderr> always works.

But back in 2012, Kay Sievers wanted to make it record-based, because
reasons. That *really* doesn't play well with the whole "oh, you might
not get the whole thing in one go" model, and things were broken a few
times. It also made our printk implementation a lot more complex. But
there was some argument for a full-featured syslog facility.  Line
continuations suddenly weren't very natural any more, because now a
continuation printk was very much a "broken record".

Anyway, the complexity has had upsides too, and the "let's not require
'\n' at the end" actually came in through that (in fact, I think the
record-based internal format removes the newlines at the end of
characters). And there are some real advantages, both with timestamps
and with having per-record log levels. So it's definitely not all bad,
but there's a fair amount of complexity in there. The old model was
rather broken in other ways, though, so on the whole I think we're
doing fairly ok.

But yes, the line continuation that *used* to be very natural (but
always had problems with concurrent output from multiple contexts)
definitely makes for extra complexity in the record-based model. But
exactly *because* the record-based thing needs to be more careful
about those newlines, it actually ended up being why the explicit "\n"
thing at the end of a printk shouldn't really matter any more.

And not having it does make for nicer printk strings. "Just the facts".

             Linus