Re: [RFC PATCH] cmdline: Hide "debug" from /proc/cmdline

[Theodore Ts'o]

On Fri, Apr 04, 2014 at 03:44:26PM -0400, Steven Rostedt wrote:
> I saw one commenter say that this was a kernel bug because writing to
> kmsg shouldn't cause the system to hang.
> 
> The rate-limit patch would go along with that idea, and I honestly
> think it would be good to rate-limit it in case something else breaks
> and starts spamming kmsg.

I agree; the only question is what is the appropriate rate limits,
which is the question Linus was asking.

Personally, I like keeping the current limits (no more than ten
messages every 5 seconds) because I don't think dmesg, which is a
circular buffer and deliberately kept simple so that printk is
guaranteed to work even when things go really bad (and if things do go
really bad, there are ways of reading dmesg out from a crash dump, for
example, so we want to keep things simple).

Peter has argued that it might be cool if the Kernel had a
purpose-built in-kernel syslogd sort of interface, that could accept
arbitrarily large amounts of data, and presumably it would allocate
memory as needed, and since the kernel knows this is log data, if we
are under memory pressure, it could release some of the log data, even
if the userspace hasn't picked it up yet, under extreme memory
pressure.

I don't know that it makes sense to do this, since IMHO we can just as
easily do this in a user-space process.

But I *do* think we should keep the facility used by printk to be as
simple and as bulletproof as possible, which means we should really
try to keep users of /dev/kmesg to the simple "I'm starting test
<foo>", or similar messages.  And that argues for using things like
the current ratelimit defaults.

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