global tracing

[Roland McGrath]

> Actually, this point is where I'm stuck on these weeks.
> 
> If we add marker or tracepoint to trace every syscalls,
> we might have to put it in the tracehook or audit and set
> TIF_SYSCALL_TRACE for every process, or put tracepoint
> in the syscall entrance/exit asm-code and check another
> flag. Since latter adds additional flag-checking in fast-path,
> I think it is not acceptable.

I agree completely that it would be wrong to do any new arch work for this,
especially assembly hacking.  Certainly piggy-backing on the existing
TIF_SYSCALL_TRACE or TIF_SYSCALL_AUDIT in some fashion is the way to go.

If you don't need complete user register access at your tracepoint, then
the audit path is an option.  I suspect you do, and so TIF_SYSCALL_TRACE
is what to use.  Then you can put tracepoints in tracehook_report_syscall_*.

It's straightforward to write a loop to set TIF_SYSCALL_TRACE on every
task.  The only wrinkle is dealing with clearing the flag correctly.  You
don't need a loop, because it can be cleared lazily by each thread when it
gets into the slow path and finds it has no reason to be there.  This is
not very hard.  It only requires adding a few lines in the utrace code to
check your global-syscall-trace flag in deciding when to clear
TIF_SYSCALL_TRACE.

This would be unlike a plain tracepoint only in that you have to make this
explicit call to switch it on and off.  (Maybe this could be rolled into
the tracepoint probe registration API.)

I'm not at all arguing against having utrace global tracing to provide you
this feature instead.  (I already raised the pros/cons about that generally
and that discussion can continue.)  But this is how you'd do it sensibly
with tracepoints IMHO.  (The details I just described are not much different
from what utrace global tracing would have for handling TIF_SYSCALL_TRACE.)


Thanks,
Roland