Possible performance bug

[Steve Grubb]

On Thursday 08 September 2005 19:31, Chris Wright wrote:
> It seems odd a benchmark that runs after -e0 (that's creating only new
> processes) would be that penalized.

Agreed, that's why I think we need to dig into this to see where it leads.

> Profiles would be helpful. Actually, it'd be interesting to see overhead of
> audit turned on, but not generating any records (no rules loaded, no avc
> messages). 

True. I'll see if we can get those.

>
> Not sure what you mean by reap, normal task destruction will still reap
> those.

I mean claim the memory used by the context and set context = NULL so that 
syscall_exit no longer gets penalized.

> But it's a valid question if disabling audit should disable 
> audit_exit.  Any pending audit records would be lost.

The act of issuing auditctl -e 0 is not precise, there could always be 
something lost.

> Trying to proactively reclaim contexts when disabled would mean long running
> processes would no longer get audited if an admin did disable/enable.

It would seem that whatever made the program auditable would still be true and 
a context would eventually get generated for it if it indeed was of interest. 
Maybe changing the if (likely(!context)) to if (likely(context == NULL || 
audit_enabled == 0)) would solve the problem.

-Steve