audit_log_drain

[Chris Wright]

* Steve Grubb (sgrubb at redhat.com) wrote:
> On Wednesday 06 April 2005 12:00, Steve Grubb wrote:
> > The fact is that as long as we have space in the backlog, we don't have to
> > lose a packet do we?
> 
> Specifically, I'm talking about this:
> 
> 522                 if (retval == -EAGAIN && ab->count < 5) {
> 523                         ++ab->count;
> 524                         skb_queue_tail(&ab->sklist, skb);
> 525                         audit_log_end_irq(ab);
> 526                         return 1;
> 527                 }
> 
> ab->count < 5 sounds arbitrary. I'd rather see it:
> 
> 	if (retval == -EAGAIN && audit_backlog < (audit_backlog_limit-1))
> 
> Does this make more sense? The idea is to try to leave room for 1 more packet 
> that could trigger the audit_log_drain.

That's different.  5 retries per audit buffer (yes I agree sounds random,
no idea where it came from), which could have multiple skb's.  But max
outstanding audit_buffers of audit_backlog_limit.  I messed with this a
while back, and I found the retry logic was nearly always just a small
delay to "netlink socket too busy".  So, I agree, there's room for
improvement.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net