Possible performance bug

[Chris Wright]

* Steve Grubb (sgrubb at redhat.com) wrote:
> I was looking at the case where a user boots up with audit daemon installed. 
> It turns on auditing. This means that all processes that fork will start 
> getting a context built. Then the user decides to do a benchmark and turns 
> the audit system off by auditctl -e 0.
> 
> The system doesn't really get performance back as if auditing was never turned 
> on. If you look at audit_syscall_exit, there is this check:
> 
>         if (likely(!context))
>                 goto out;
> 
> Don't all the running processes still have a context?

Already running processes would (except those with 'never' rules), but
news ones shouldn't (new meaning after -e0).  It seems odd a benchmark
that runs after -e0 (that's creating only new processes) would be that
penalized.  New processes would have no context, and existing processes
would bail out of audit_syscall_entry.  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).

> Shouldn't this also have 
> a check that if audit_enabled == 0, that the context is reclaimed and context 
> set to NULL? What reaps the context for these processes. They all still seem 
> to be penalized.

Not sure what you mean by reap, normal task destruction will still reap
those.  But it's a valid question if disabling audit should disable
audit_exit.  Any pending audit records would be lost.  Trying to
proactively reclaim contexts when disabled would mean long running
processes would no longer get audited if an admin did disable/enable.

thanks,
-chris