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
| ||
|
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.
Powered by blists - more mailing lists