Emmanuel Dreyfus wrote:
> So we said we want the kernel to avoid writting the RET execve in the
> trace. It seems it should be done in kern_ktrace.c:ktrsysret(), testing
> on the code parameter.

Well, it has not be decided if we 'want' it that way, I just expressed
preference for that way. Since it's personal taste thing only, my
suggestion is as good as your solution :)

Doing it in ktrsysret() won't probably work unfortunately, though. Linux
uses -errno as return value for 'error' path. If the errno is
ENOENT, the emulation code ends up calling ktrsysret() with retval
-2 == EJUSTRETURN and the record would not be written. This is probably
not anything you want.

Note that you also want to ignore ERESTART - that is also never
passed to userland, just makes kernel adjust process PC accordingly.
So the ktrace RET record should not be written for it in ideal world, too.
 
> But how can we know what is execve's code? seeking sys_execve address in
> sysent[] seems a very bad idea to me: it's not emulation friendly, and
> it's time consuming to do it each time. Is there any other way?

You probably don't need to know that the syscall was execve(2).  AFAIK
EJUSTRETURN as a 'return' value from syscall is only used by
execve(2).

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>      http://www.ics.muni.cz/~dolecek/
@@@@  Wanna a real operating system ? Go and get NetBSD, dammit!  @@@@