On Fri, Apr 4, 2014 at 1:17 PM, Theodore Ts'o <ty...@mit.edu> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
