[PATCH 2/2] Trace fork series calls using PTRACE_SETOPTIONS on linux

Roland McGrath roland at redhat.com
Thu Sep 2 01:29:50 UTC 2010

Unfortunately, it's not quite that easy.  There were some older kernels
that had PTRACE_SETOPTIONS but did not support PTRACE_O_TRACECLONE et al,
and also did not check the argument to PTRACE_SETOPTIONS, so they just
return success without actually enabling the feature you wanted.

So, when PTRACE_SETOPTIONS succeeds, then you still need to assume that
PTRACE_O_* is not enabled until you manifestly get a wait result that uses
PTRACE_EVENT_CLONE et al.  So, the existing code needs to stay as it is for
at least the first run of a clone*/*fork call.  Then, if the kernel really
supports the feature, you will get a PTRACE_EVENT_{CLONE,*FORK} stop after
that syscall-entry stop and before its corresponding syscall-exit stop.
When that happens, you can record that the kernel really does support the
feature and then for the next clone*/*fork syscall you won't need to bother
with the old code (though you still need to finish up in the old fashion at
that syscall's exit stop).

Also note that Andreas had submitted a patch to use PTRACE_SETOPTIONS for
another purpose (PTRACE_O_TRACEEXEC).  That use also has to cope with the
kernel support level issue in the same dynamic and resilient fashion.
These should obviously share some code and play well together.
Unfortunately, Andreas stopped discussing the issues related to exec
changes I raised while reviewing that patch, and the change was never


More information about the Strace-devel mailing list