linux-kernel - Re: [PATCH v3] printk: Have printk() never buffer its data

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:	Mon, 25 Jun 2012 16:55:31 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Andrew Morton <akpm@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	"kay.sievers" <kay.sievers@...y.org>,
	Wu Fengguang <fengguang.wu@...el.com>,
	Joe Perches <joe@...ches.com>,
	"Paul E. McKenney" <paulmck@...ibm.com>
Subject: Re: [PATCH v3] printk: Have printk() never buffer its data

On Mon, Jun 25, 2012 at 03:07:22PM -0700, Andrew Morton wrote:
> On Mon, 25 Jun 2012 15:05:42 -0400
> Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > 
> > This brings back the old way of printk() that always prints to the console
> > and does not buffer the data. As printk_emit() is used by other 'facilities'
> > this only affects printk(), but keeps pretty much the new behavior.
> 
> If you say so.  The core printk code is starting to make one think of
> things like "cleansing with fire".
> 
> Why did that logging code need to futz with this printk behaviour in
> the first place?

Because, as Kay, and I think Linus, showed a while ago, the behavior
really wasn't all that good and it wasn't doing what people thought it
was doing, especially when printks from multiple cpus happened at the
same time.  There were other cases that had problems as well, the long
thread a few months ago detailed it all, which drove the creation of
these changes.

> I don't think the thing which you're fixing here was a real
> showstopper.  If a non-newline-terminated printk gets delayed, then so
> be it - we identify and fix all callers and remember the new rule and
> move on, although I still don't know why this change was deemed
> necessary.  If that results in a cleaner, clearer and more reliable
> core printk() then we win.

I'm beginning to agree here as well.

Actually, didn't I say that at the beginning of this?  :)

Stephen and Ingo, I understand that your tests now would require
multiple printk() lines, but this affects what, 10 boxes in the world
that run these tests (I'm not trying to be mean, just understand the
issues).  The fixes that now are in place fix problems for many more
systems, and provide the infrastructure for proper logging that people
have been screaming at us for over 10 years to accomplish.

I'll be glad to make the patch to fix up these test printks, (remember,
as a bonus, you now get a timestamp showing exactly how long your tests
take, which you didn't get before, how can you pass up an offer like
that?)  I think that's the best solution here, and easiest for everyone
involved (your tests then properly show what failed, you get bonus
timestamps, multi-cpu printks happen properly, proper logging messages
get sent to userspace, everone wins.)

> And we do need a cleaner, clearer and more reliable core printk() :(
> wtf have you guys been up to??  

See, Andrew even agrees with me :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/