linux-kernel - Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length record buffer

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:	Tue, 8 May 2012 15:33:03 +0200
From:	Sasha Levin <levinsasha928@...il.com>
To:	Kay Sievers <kay@...y.org>
Cc:	Greg Kroah-Hartmann <greg@...ah.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND 1/3] printk: convert byte-buffer to variable-length
 record buffer

On Tue, May 8, 2012 at 1:14 PM, Kay Sievers <kay@...y.org> wrote:
> On Tue, 2012-05-08 at 10:48 +0200, Sasha Levin wrote:
>> This patch was included in today's linux-next, and it looks like it
>> broke printk on my configuration.
>>
>> It's a bit hard to describe exactly what's wrong, but here are the main points:
>>
>> 1. PRINTK_TIME timing information is gone.
>
> It's always unconditionally recorded now. It looks fine in 'dmesg'
> output, right?

Yup. Is there no intention to show it in the console output though? it
was quite handy there.

>
>> 2. Newline issues. It appears to be adding newlines where it
>> shouldn't.
>
>> parport0: PC-style at 0x378
>> , irq 7
>>  [
>> PCSPP
>
> Yeah, we need to make sure, we never merge the (always racy)
> continuation printk() users with (non-racy) non-continuation users.
> Therefore KERN_CONT is required to suppress the newline and to merge the
> content with the earlier non-newline-terminated printk() line.
>
> I 'm sure, I have signed up for the job to fix what's needed here. :)
>
> Patch for parport is below.
>
>> 3. Things are not properly aligned, such as stack traces.
>
> Mind sending the entire output of your 'dmesg', which shows it?
>
> We recently just needed to fix the "<%u>" in the dump, which got
> recognized as syslog prority prefixes. There might be a few more
> KERN_CONT missing ...

The 3rd one actually looks like the KERN_CONT problem now that you've
explained it. You can see it in the 'saved trace' test in the boot
log.

I've attached the boot log which shows several other places with this
issue, if you're ok with it I can try patching those myself.

View attachment "log.txt" of type "text/plain" (73182 bytes)