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