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]

Message-ID: <1475912203.2856.1.camel@perches.com>
Date:   Sat, 08 Oct 2016 00:36:43 -0700
From:   Joe Perches <joe@...ches.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     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, 2016-10-07 at 14:37 -0700, Linus Torvalds wrote:
> On Fri, Oct 7, 2016 at 2:06 PM, Linus Torvalds
> <torvalds@...ux-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:
> 
> commit 61e99ab8e35a88b8c4d0f80d3df9ee16df471be5
> Author: Joe Perches <joe@...ches.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.
> 
> So you are literally the person who broke this.
> 
> Goddammit, I don't want to hear another peep from you. You broke this
> because you wanted to save a few bytes in those strings, and then
> *because* you broke it, you then argue for putting those bytes back in
> the form of "\n" characters.
> 
> Fuck me sideways. You make this big deal about how this interleaving
> is a big problem, and at no point did you actually point to the real
> issue, which was your very own breakage where you made it all fragile.

The _only_ person that's making a "big deal"
out of it is _you_. 

And I believe you are wrong here.  Both about the
original behavior and the effect of the change I made.

I'm not swearing, I'm just commenting.
In no case is a comment anything like a "big deal".

And the only thing that commit did was avoid
skipping forward in the format.  It didn't have
anything to do with interleaving.

The logging code for v3.5 and v3.6, (pre and post
this patch) both of which I just tested, emit these
on a single line

	printk(KERN_INFO "format");
	printk(" continued on the same line\n");

Same as

	pr_info("format");
	pr_cont(" continued on the same line\n");

neither dmesg nor /dev/kmsg show any difference.