On Sun, Apr 26, 2020 at 06:34:30PM +0200, Hagen Paul Pfeifer wrote: > Working on a safety-critical stress testing tool, using ptrace in an > rather uncommon way (stop, peeking memory, ...) for a bunch of > applications in an automated way I realized that once opened processes > where restarted and PIDs recycled. Resulting in monitoring and > manipulating the wrong processes. > > With the advent of pidfd we are now able to stick with one stable handle > to identifying processes exactly. We now have the ability to get this > race free. Sending signals now works like a charm, next step is to > extend the functionality also for ptrace. > > API: > long pidfd_ptrace(int pidfd, enum __ptrace_request request, > void *addr, void *data, unsigned flags); I'm in general not opposed to this if there's a clear need for this and users that are interested. But I think if people really prefer having this a new syscall then we should probably try to improve on the old one. Things that come to mind right away without doing a deep review are replacing the void *addr pointer with a dedicated struct ptract_args or union ptrace_args and a size argument. If we're not doing something like this or something more fundamental we can equally well either just duplicate all enums in the old ptrace syscall and append a _PIDFD to it where it makes sense. Christian
