Re: Possible performance bug
* Steve Grubb (sgrubb(a)redhat.com) wrote:
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.
I'm with you.
> 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.
Great. Should be interesting to see the results.
> 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.
Right, during syscall_exit if disabled, cleanup...
> 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.
...which is why I mentioned that. The syscall_entry is only testing !context
so it would permanently stop auditing that task once the context was reaped.
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.
I'm not sure it would. It depends on what's expensive here. It would
help in the case where there's no rules loaded. But in that case, the
overhead should already be low. No rules means audit_get_context should
be light, and !context->auditable so audit_log_exit itself should be
light. The getname/putname bit is cheap too. So we've got the overhead
of a few extra branches, a few extra assignments (including the memset
of the context). Sure, there's overhead, but I'd be surprised if it made
large impact on macro benchmarks.
If there were lots of rules loaded when audit was disabled, then the
filter done during audit_get_context on syscall_exit could start to
get expensive. If that's the case, then the audit_enabled == 0 check
wouldn't help unless it was also done in audit_get_context (which would
screw up freeing). Perhaps audit_enabled should be checked before running
filter rules if that's the expense.
thanks,
-chris