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