Possible performance bug

[Steve Grubb]

On Friday 09 September 2005 12:46, Chris Wright wrote:
> Good point.  In fact, audit_alloc should probably clear that if disabled.

I am thinking about something like this:

diff -ur kernel-2.6.9.orig/linux-2.6.9/kernel/auditsc.c kernel-2.6.9/linux-2.6.9/kernel/auditsc.c
--- kernel-2.6.9.orig/linux-2.6.9/kernel/auditsc.c      2005-08-01 18:36:44.000000000 -0400
+++ kernel-2.6.9/linux-2.6.9/kernel/auditsc.c   2005-09-09 12:28:58.000000000 -0400
@@ -749,9 +749,6 @@
        struct audit_context *context;
        enum audit_state     state;

-       if (likely(!audit_enabled))
-               return 0; /* Return if not auditing. */
-
        state = audit_filter_task(tsk);
        if (likely(state == AUDIT_DISABLED))
                return 0;
diff -ur kernel-2.6.9.orig/linux-2.6.9/kernel/fork.c kernel-2.6.9/linux-2.6.9/kernel/fork.c
--- kernel-2.6.9.orig/linux-2.6.9/kernel/fork.c 2005-08-01 18:36:44.000000000 -0400
+++ kernel-2.6.9/linux-2.6.9/kernel/fork.c      2005-09-09 12:29:44.000000000 -0400
@@ -1011,8 +1011,12 @@

        if ((retval = security_task_alloc(p)))
                goto bad_fork_cleanup_policy;
-       if ((retval = audit_alloc(p)))
-               goto bad_fork_cleanup_security;
+       if (likely(audit_enabled == 0))
+               clear_tsk_thread_flag(p, TIF_SYSCALL_AUDIT);
+       else {
+               if ((retval = audit_alloc(p)))
+                       goto bad_fork_cleanup_security;
+       }
        /* copy all the process information */
        if ((retval = copy_semundo(clone_flags, p)))
                goto bad_fork_cleanup_audit;


The only problem I see is when audit is re-enabled, we need a way to start getting the 
TIF_SYSCALL_AUDIT flag set again for already running processes. For example, suppose
apache was of interest and audit was disabled. The above code would remove the flag.
Then when audit is re-enabled, we need to set the flag again. I'm looking for a low impact
way of doing this. Still thinking.

> But ISTR numbers of the order audit slows benchmarks down 20%.  This is
> not going to give 20% overhead.

True. I think that number means optimizing the filters and everything touched by 
syscall_entry exit. The speedup-more patch should help this somewhat. But more
work is needed. 

-Steve