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