lkml.org 
[lkml]   [2008]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] printk: robustify printk

* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> > The problem is that it means any printk data output that is more
> > than DMESG-BUFFER-SIZE bytes during one clock tick is going to lose
> > data. It loses the natural adaption to higher printk rates that you
> > got previously.
> >
> > Now we could say that for debugging etc. people should switch to
> > other mechanisms like relayfs, but I would still worry about some
> > corner cases where losing printk data that wasn't lost before could
> > be a severe regression (e.g. consider firewall log messages or
> > similar)

That's a rather misleading argument, because klogd as it stands today is
already lossy: you can overflow it with enough printk data. (It's rather
easy to trigger it as well, so nobody sane relies on it as a reliable
channel.)

Using relayfs and dynamic buffers would be a much worse approach because
if we are out of buffer space it would be a robustness disaster to start
allocating more RAM. (we want less coupling of printk to other kernel
subsystems, not more coupling) Preallocating wont help either because it
doesnt protect against sudden spikes.

> You only loose the msgs with klogd, console still gets everything. If
> firewalls are generating that much data, perhaps its time to think
> about alternative ways to channel that.

yeah, and note that klogd as it stands today is a lossy channel no
matter what - there's nothing that keeps a really verbose kernel from
flooding the buffer.

The issue Andi raises is largely independent of this change and there's
three clean options to deal with it:

- increase buffering (already possible, see CONFIG_LOG_BUF_SHIFT)

- create a more reliable klogd channel with a dynamically
shrinking/growing buffer (i very much doubt the complexity is
worth it, and this one wont be 100% loss-less either)

- use a reliable console

#1 is what distros use to maximize the yield of user bugreports, and #3
is what everyone who ultimately cares about massive printk output and
reliable logging uses.

Ingo


\
 
 \ /
  Last update: 2008-08-11 14:05    [from the cache]
©2003-2011 Jasper Spaans. Advertise on this site