On Thu, Jun 20, 2019 at 06:11:44AM +0300, Dmitry V. Levin wrote: > Initialize pidfd to an invalid descriptor, to fail gracefully on > those kernels that do not implement CLONE_PIDFD and leave pidfd > unchanged. > > Signed-off-by: Dmitry V. Levin <l...@altlinux.org> > --- > samples/pidfd/pidfd-metadata.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/samples/pidfd/pidfd-metadata.c b/samples/pidfd/pidfd-metadata.c > index 14b454448429..ff109fdac3a5 100644 > --- a/samples/pidfd/pidfd-metadata.c > +++ b/samples/pidfd/pidfd-metadata.c > @@ -83,7 +83,7 @@ static int pidfd_metadata_fd(pid_t pid, int pidfd) > > int main(int argc, char *argv[]) > { > - int pidfd = 0, ret = EXIT_FAILURE; > + int pidfd = -1, ret = EXIT_FAILURE;
Hm, that currently won't work since we added a check in fork.c for pidfd == 0. It it isn't you'll get EINVAL. This was done to ensure that we can potentially extend CLONE_PIDFD by passing in flags through the return argument. However, I find this increasingly unlikely. Especially since the interface would be horrendous and an absolute last resort. If clone3() gets merged for 5.3 (currently in linux-next) we also have no real need anymore to extend legacy clone() this way. So either wait until (if) we merge clone3() where the check I mentioned is gone anyway, or remove the pidfd == 0 check from fork.c in a preliminary patch. Thoughts? Thanks! Christian