[patch] fix syscall speedup patch mips typo

[Amy Griffis]

On Thu, Mar 16, 2006 at 01:29:19PM -0500, Jason Baron wrote:
> > This patch avoids the record that would be generated on syscall exit,
> > but then emits it as AUDIT_SYSCALL_PARTIAL when the task exits.
> > Previously, these contents would be logged on every syscall exit, and
> > would only be logged on task exit in the case that it happened prior
> > to syscall exit.
> 
> This is bug in the implementation then...i had intended to to have
> syscall partials only emitted at syscall exit time, when say after
> selinux created an avc message. Is this hard to fix?

I see now that it works as you describe.  I had missed the
significance of the invoke_audit field in the audit_context.

On Thu, Mar 16, 2006 at 02:46:47PM -0500, Steve Grubb wrote:
> 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.

On what architecture(s) did you do your profiling?  The audit context
is always allocated on task creation, and will only be allocated
(again) in syscall entry in special circumstances.  Per the comment in
audit_syscall_entry(), this only happens on architectures that make
system calls in kernel_thread via the entry.S interface instead of
with direct calls.

> 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.

Of what value is a syscall record if it doesn't give you the syscall
number?

The audit system has set of defined states that determine its
activities around context collection, filtering, and logging.  This
patch attempts to circumvent that set of states in a dubious manner to
meet a questionable requirement.  This is precisely the kind of code
that makes audit non-intuitive, fragile, and unpopular in the linux
kernel.

> 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.

Those people can set audit_enabled=0, problem solved.  Steve, please
provide evidence of users needing avc messages with partial syscall
records, and which information in the syscall record is required.
There's no point in a patch for a non-existent requirement.

Regards,
Amy