linux-kernel - Re: Wait for console to become available, v3.2

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, 21 Apr 2009 10:59:52 -0700
From:	David VomLehn <dvomlehn@...co.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	David Brownell <david-b@...bell.net>, alan@...rguk.ukuu.org.uk,
	Ingo Molnar <mingo@...e.hu>,
	Arjan van de Ven <arjan@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux USB Mailing List <linux-usb@...r.kernel.org>,
	Linux Embedded Mailing List <linux-embedded@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Wait for console to become available, v3.2

 Tue, Apr 21, 2009 at 10:37:41AM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 21 Apr 2009, David VomLehn wrote:
> > 
> > What in the world are users going to do when they see a message about
> > output being lost? There is no way to recover the data and no way to
> > prevent it in the future. I don't think this is a good approach.
> 
> Sure there is. The console messages are saved too, so doing 'dmesg' will 
> get you all the data that was generated before the console went on-line.
> 
> We _already_ lose data in that sense (although we could replay it for the 
> first console connected - maybe we even do, I'm too lazy to check).

There are two different things coming out on the console, kernel log buffer
messages and userspace output to /dev/console. Kernel log buffer output
is replayed for each console as it connects. There might be quite a bit of
it, but it is pretty much the same from boot to boot, so the guy working on
the kernel, me, can tune the size of log_buf pretty easily. This is not
the problem.

The problem is the userspace output to /dev/console. I work in the embedded
space and my box does not simply throw up a few windows and wait placidly for
the user to do something. Instead, it immediately starts running a whole bunch
of software with a whole bunch of startup messages. In short order, I am
running over 300 threads. I have no control over how much output comes out,
I have no idea how much kernel memory to allocate for this, and I'm quote sure
it's enough that I wouldn't want to waste that much space even if I did. No
matter what, this looks like we'd need a new tunable for the size.

And then, what happens if I *never* get a console, because one isn't plugged
in? This happens a lot in the embedded world. How long am I supposed to keep
around this big chunk of buffered data? Sounds like I need *another* tunable.
Yuck.

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