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

[Alexei Starovoitov]

On Fri, Apr 4, 2014 at 1:17 PM, Theodore Ts'o <tytso@xxxxxxx> wrote:
> 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.

can there be two bulletproof buffers: one for in kernel printk
and another ratelimited one for writes into /dev/kmsg.
On the read from /dev/kmsg they're combined by time.
--
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/