linux-kernel - Re: [PATCH] printk: Add printk_flush() to force buffered text to console

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: <1340304566.27036.200.camel@gandalf.stny.rr.com>
Date:	Thu, 21 Jun 2012 14:49:26 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Joe Perches <joe@...ches.com>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Fengguang Wu <fengguang.wu@...el.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"kay.sievers" <kay.sievers@...y.org>,
	"Paul E. McKenney" <paulmck@...ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] printk: Add printk_flush() to force buffered text to
 console

On Thu, 2012-06-21 at 11:39 -0700, Joe Perches wrote:

> > A global buffering disable may cause other things that are printed to be
> > screwed up.
> 
> After Kay's deferral patch (an actual improvement), lots
> of output could have been changed.  Turning off buffering
> would simply revert to pre 3.5 behavior.  I don't think
> that's a significant issue.

But prints that actually require buffering disabled (like the one I'm
using) does so because it may be testing something that may crash the
system. On SMP, that crash could cause garbled output. Yes, it is pre
3.5 behavior, but why have garbled output on the crash when Kay went
through all that effort to have it work.


> 
> > Something that actually expects to be buffered.
> 
> There is nothing today that _expects_ buffering or is
> guaranteed non-buffered.

I'm not saying there is. But if the new buffering system is here, then
there may be something that will _expect_ buffering to be enabled.

> 
> The locations that benefit from non-buffering are few
> and isolated.

Which means we can use individual flushing.

> 
> > Or perhaps have printk_flush() become a new printk. That is,
> > printk_flush("this does not buffer").
> 
> Yuck.
> 
> Then there'd be all the likely variants for
> prefix [pr|dev|netdev]_<level>[_once|_ratelimited] postfix
> too.

Actually, I'm starting to lean back to my original patch, and stick a
pr_flush() in there. As it basically just acts like a barrier. "Make
sure the output I printed actually gets out to the console before I
continue".

-- Steve


--
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/