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

[Wang Chao]

Sent on 2010-9-2 9:29, Roland McGrath wrote:
> 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.
Well, after I played a little with the kernel code, I found that
PTRACE_O_TRACECLONE et al options were supported since 2.5.46 and
the arguments passed to PTRACE_SETOPTIONS were fully checked. So I
am wondering what you said will only occur on 2.4 and early 2.5
kernels, and won't cause problems with 2.6 series.

If so, I guess that what you want is the compatibility with system
using early 2.4 kernels. But I am in doubt whether we need to do so
since 2.4 series are really too old, right?

Moreover, if I got all right, in old kernels such as 2.4 series,
wait call will lost its children who are ptraced. I guess that's
why strace have function internal_wait. But in 2.6 series kernels,
I think wait call will block if its children are currently ptraced
and strace does not need to do any additional work here. Doing so
in 2.6 will make things much more complex if wait call use pgid or
options such as __WCLONE. I'm not very sure about this.

> 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).
Yes, in this way we can gain good compatibility with older kernels.
But at the same time, we have also lost the benefits of using
PTRACE_SETOPTIONS. For example, with old code, we still can not
really trace vfork, while this can be easily done with PTRACE_SETOPTIONS.

I'm sorry if I don't understand correctly.

Thanks,
Wang Chao