[PATCH] ratelimit printk messages from the audit system

[Paul Moore]

On Wednesday 23 January 2008 5:06:53 pm Linda Knippers wrote:
> Eric Paris wrote:
> > On Wed, 2008-01-23 at 16:05 -0500, Linda Knippers wrote:
> >> This is unrelated to your patch but I think it would be nice if
> >> audit_lost represented the number of audit messages lost since the
> >> last time the message came out or the last time an audit record
> >> came out. Today its a cumulative count since the system was
> >> booted.  Is it too much overhead to zero it?
> >
> > Shouldn't be too much overhead, we are already on a slow/unlikely
> > path. What's the benefit though?  Just don't want to have to do a
> > subtraction?
>
> Well that, plus if the system is up for a long time (which we hope)
> and the message is infrequent (which we also hope), then it could
> take me a while to find the previous message in order to do the
> subtraction.
>
> > If we are dropping the 'we lost some messages' message 0'ing the
> > counter at that time would be a bad idea, certainly not unsolvable,
> > but I don't see what it buys us.
>
> I wouldn't want to lose the message, just make it more useful.  And
> if we zero it we don't have to worry about it wrapping.  As it is
> now, its really just the count since the last time it wrapped.

I like Linda's idea of zero'ing the lost message counter once we are 
able to start sending messages again for all the reasons listed above.  
I haven't looked at the audit message sending code, but we are only 
talking about adding an extra conditional in the common case and in the 
worst case a conditional and an assignment.  Granted they are atomic 
ops, but everyone keeps telling me that atomic ops are pretty quick on 
almost all of the platforms that Linux supports ...

-- 
paul moore
linux security @ hp