Re: [patch] fix syscall speedup patch mips typo

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