Re: [PATCH 4/6] trace: trace syscall in its handler not from ptrace handler

["H. Peter Anvin" <hpa@zytor.com>]

On 03/28/2012 11:23 AM, Vaibhav Nagarnaik wrote:
> 
> I am sorry I don't see how that would be possible without having some
> sort of architecture dependent changes.

Tough, that's sometimes the way it goes.  On most architectures it's
just a simple table.

> Also as you mentioned, it will have some security considerations.

Not any more than your little scheme.

> If you can suggest a better way without going through this macro
> magic, I will be glad to implement it. The 2 main reasons I made this
> patch was to remove the added latency in syscall tracing and to remove
> penalty for syscalls that are not traced.

But instead you add a penalty for every syscall, even if tracing is
disabled.  Not cool.

> If you can suggest a better way without going through this macro
> magic, I will be glad to implement it.

The more I look at this stuff the more I think it is not just crazy, but
batsh*t crazy... we produce *how* much "metadata" which is stored in
non-pageable kernel memory, and all it seems to be *actually* doing is
store a variable number of parameters in a buffer.

This is insane.  Not just a little insane, but utterly bonkers.

The syscall interface is the single most stable interface in the kernel.
 Just plunk down the system call number and the six arguments in the
buffer, and be done with it.  On the way out, there is a single return
argument, *by design*.  No need to burden the kernel in this way! That
this information can be perfectly well decoded in userspace is already
shown by strace, although it would be highly beneficial if the kernel
build could export information to strace and other tools.  There is
absolutely no need for it to live in kernel memory, though.

	-hpa