Re: [PATCH] ratelimit printk messages from the audit system

On Thu, 2008-01-24 at 12:52 -0500, Paul Moore wrote: > 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 ... Delivery of audit lost messages is through printk/syslog. Assuming we can assure it gets out of printk when we reset the counter we can't assure that it made it to syslog. That means we could lose that message and have no record of it at all, nor any chance that in the future it would get recorded that it was lost either.

I wouldn't NAK such a patch, but at the same time don't anyone expect me to write it :)