Messages in this thread | | | Date | Wed, 28 Mar 2012 19:43:06 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [PATCH 4/6] trace: trace syscall in its handler not from ptrace handler |
| |
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
| |