> 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