Rethinking race-free process signaling

Posted Apr 8, 2019 20:41 UTC (Mon) by jkowalski (guest, #131304)
In reply to: Rethinking race-free process signaling by nix
Parent article: Rethinking race-free process signaling

There were plans of making the non-proc pidfds pollable and readable, but if you go with /proc descriptors you need to implement all of that over the dir fd's file ops.

That's not very problematic (from an API perspective it is very weird, but not internally), but my idea was pidfd_open could take some wait flags as waitfd did (and check if you're one of parent or real_parent, and only return a readable descriptor), among other things, and that intent cannot be described easily when opening a directory in /proc. This means everyone can poll but perhaps only parents (real or tracing) would be able to open a readable instance.

I can only hope this is taken into consideration (I raised this exact problem as I ran into it as well), and /proc descriptor stuff be removed, as it brings more problems for future extensions.

You could ofcourse resurrect a waitfd too, again, but I see no point when you could return a pollable/readable descriptor from clone and pidfd_open (and possibly even disable termination signals and autoreap them - the whole act of waiting is asynchronous). It also has a nice touch of consistency to it (and the fact that resources in a different namespace suddenly aren't addressable and can be taken a reference to from a different namespace - the filesystem), in that sense pidfd_open isn't very different from open, but it works like open only on PIDs you can *see* (unlike /proc, which is leaky across shared mount namespaces but separate PID namespaces).

Rethinking race-free process signaling

Posted Apr 9, 2019 15:12 UTC (Tue) by nix (subscriber, #2304) [Link]

You can use pidfd for reaping, but can you use it for waitpid() in particular? ptrace() results are not only thread-directed but also only defined in terms of waitpid() output: most of the other wait-a-likes will not suffice (e.g. waitid() throws too much information away).

(If pidfds also wake you up when non-termination waitpid() results would be returned iff you did a waitpid(.., WNOHANG), then they do seem like a complete replacement for waitfd, which is great because it means I can drop another annoying invasive patch!)

btw, this does mean that you'd need to be able to get a pidfd not only at clone time but also at PTRACE_SEIZE time, or tracers could never get hold of a useful pidfd at all...