[rfc] how should we support pidfds for ProcfsBase?

[cyphar]

ProcfsBase::ProcPid (#205) is inherently racy because of pid recycling, which pidfds are intended to solve. However, it isn't necessarily obvious to me how we should handle using pidfds.

I guess we could:

• For old-style pidfds we can probably just detect them by checking for the stat subfile and reading the first field to get the pid. We could also just use it as the root of the lookup, but we cannot really be sure it is a "real" pid directory.
• Use PIDFD_GET_INFO on the newest kernels (for "new"-style pidfds).
• Parse /proc/self/fdinfo/$fd to get the Pid: value (for "new"-style pidfds) as a fallback for older kernels.

And then after opening the base directory, we check whether the process is still alive with pidfd_send_signal(signo=0) (which will even work with processes we do not have privileges to send signals to -- you get ESRCH vs EACCES). If the process died then we return ESRCH. We could also do the check again before returning, but that's probably not necessary.

However, for everything other than PIDFD_GET_INFO, one issue we have is that the pid we get from pidfd might be different to the one we would see in our procfs handle (for old-style pidfds the procfs might be from a totally different pidns, while for regular pidfds ). In principle we could parse NSpid (for fdinfo) but we won't know which pid is correct. And unfortunately there appears to be no way of verifying if an old-style pidfd and a new one are the same thing (i.e. /proc/1234 and pidfd_open(1234)).