Re: Possible performance bug
* Steve Grubb (sgrubb(a)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