[patch] fix syscall speedup patch mips typo

Steve Grubb sgrubb at redhat.com
Thu Mar 16 19:46:47 UTC 2006


Hi,

I think some people are misunderstanding what this patch is doing. The basic 
idea is that 99.999% of the people that use the audit system are running it 
to collect avc messages. When they do that, there is a performance hit that 
some people do not like.

We did some profiling to see where the kernel is spending its time. It turns 
out that the allocating of a context on every syscall is eating up clock 
cycles. It would do this regardless of any audit rules being loaded or not. 
So, if there are no audit rules loaded, why go into audit_syscall_entry at 
all? The patch is supposed to look to see if there are any audit rules loaded 
and avoid all that overhead if not. This is the typical setup for most people 
that are using targeted policy.

So, we looked at what would be missing if we did this. Basically, if we avoid 
audit_syscall_entry, syscall, arch, and args would not get collected. So, it 
would be dishonest to to put 0 into syscall or arg0. Someone somewhere would 
say the audit system is putting bogus information into syscall records. The 
idea was to create a new record type that does not have those fields in it at 
all.

We measured the results and its a big win. However, there is a bug in the 
implementation. I had a feeling there might be a bug or two since this is a 
change in what we are going and announced for people to help look for 
problems.

The patch is supposed to:

1) avoid syscall entry when there are no audit rules loaded that would 
potentially lead to a syscall event.
2) emit a partial syscall record whenever a full syscall record would have 
been emitted but there are no audit rules loaded. (Meaning we didn't collect 
entry information.)

If it doesn't do that, there's a bug in the code. We fix it, life goes on.

Does this explanation help understand what we are trying to achieve?

-Steve




More information about the Linux-audit mailing list