Re: [GIT PULL] trivial for 4.9

From: Joe Perches <joe@perches.com>
To: Linus Torvalds <torvalds@linux-foundation.org>,
	Kay Sievers <kay@vrfy.org>
Cc: Jiri Kosina <jikos@kernel.org>,
	Colin Ian King <colin.king@canonical.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] trivial for 4.9
Date: Sun, 09 Oct 2016 22:48:48 -0700	[thread overview]
Message-ID: <1476078528.2856.16.camel@perches.com> (raw)
In-Reply-To: <CA+55aFxnEd5HGbL9rk4XOs73Cd2Ji4HXBb-M_ZSx9bPq=mb2tg@mail.gmail.com>

On Fri, 2016-10-07 at 14:37 -0700, Linus Torvalds wrote:
> On Fri, Oct 7, 2016 at 2:06 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > 
> > And btw, even without an explicit KERN_<level>, you should still not
> > get any interleaving. Only an _explicit_ KERN_CONT should cause
> > interleaving
> 
> 
> Btw, note the "should" there. Because we do seem to have broken that
> _again_.  It worked fine at some point, but lookie here:

So, I've gone back to each release from 3.6 to 3.3 looking for a case
where interleaving printks inserted newlines automatically for different
processes.

I can't find one.  Neither in dmesg nor in /dev/kmsg.

What version of the kernel do _you_ think had this behavior?

> commit 61e99ab8e35a88b8c4d0f80d3df9ee16df471be5
> Author: Joe Perches <joe@perches.com>
> Date:   Mon Jul 30 14:40:21 2012 -0700
> 
>     printk: remove the now unnecessary "C" annotation for KERN_CONT
> 
>     Now that all KERN_<LEVEL> uses are prefixed with ASCII SOH, there is no
>     need for a KERN_CONT.  Keep it backward compatible by adding #define
>     KERN_CONT ""
> 
> Joe, you *are* the problem here.

It's not any release version from 3.3 to 3.6 that I can find.
Perhaps you have faster processes than I have to isolate this.

> So you are literally the person who broke this.

No, I don't think so.  Not with the patch above.
Nor with any patch I wrote from 3.3 to 3.6.

> Goddammit, I don't want to hear another peep from you.

Try again, this time with feeling.

> You broke this because you wanted to save a few bytes in those strings,

Saving code size is generally good.
I didn't break any existing behavior.

> Fuck me sideways.

I trust and hope you prefer to be the big spoon.

Newlines added to formats today _do_ help prevent
interleaving from other processes.

Is that optimal?  No.
Would I prefer no newlines for these formats?  Sure.
Does your proposal to eliminate newlines work today?  No.
Is it an easy problem to fix?  No.

For today, it's better to add newlines to formats to help
avoid random interleaving.