Only use clone3 when needed for pidfd

[cuviper]

In #89522 we learned that clone3 is interacting poorly with Gentoo's
sandbox tool. We only need that for the unstable pidfd extensions, so
otherwise avoid that and use a normal fork.

This is a re-application of beta #89924, now that we're aware that we need
more than just a temporary release fix. I also reverted 12fbabd, as
that was just fallout from using clone3 instead of fork.

r? @Mark-Simulacrum
cc @joshtriplett

[Mark-Simulacrum]

r? @joshtriplett for the master version of this -- I saw some followup discussion and you seem like a potentially better reviewer for the long(er)-term fix.

[brauner]

In #89522 we learned that clone3 is interacting poorly with Gentoo's sandbox tool. We only need that for the unstable pidfd extensions, so otherwise avoid that and use a normal fork.

This is a re-application of beta #89924, now that we're aware that we need more than just a temporary release fix. I also reverted 12fbabd, as that was just fallout from using clone3 instead of fork.

r? @Mark-Simulacrum cc @joshtriplett

In contexts where you call clone3() only to get at a pidfd and you want to avoid calling both clone() and clone3() you can simply call:

pid_t pid = fork();
if (pid)
         int pidfd = pidfd_open(pid, 0);

which let's you circumvent all of the problems that @joshtriplett is currently discussing in another thread (Not saying that this shouldn't be fixed in the relevant libcs! :)).

[bjorn3]

That is not race free. The forked process may have been killed in between. I think in the cases where pidfd should be used, it is very important that it is race free to acquire the pidfd.

[cuviper]

The forked process may have been killed in between.

The zombie will remain unless you've otherwise consumed or ignored SIGCHLD.
But let's move this to #82971, because I'm not trying to solve the whole issue in this PR.

[joshtriplett]

The zombie will remain unless you've otherwise consumed or ignored SIGCHLD.

Right, but Rust internals cant' know if that's the case.

But let's move this to #82971, because I'm not trying to solve the whole issue in this PR.

👍

[brauner]

The zombie will remain unless you've otherwise consumed or ignored SIGCHLD.

Right, but Rust internals cant' know if that's the case.

I think it should be possible to make this race-free? Rust must be in control of the actual fork() call?

[cuviper]

Rust must be in control of the actual fork() call?

Yes, but we don't know the disposition of SIGCHLD, or whether another thread is calling wait. I suspect other parts of the Command API also won't work right if you mess with that stuff though, so maybe we can write that off.

[cuviper]

@joshtriplett ping?

We'll need to backport this for 1.57 too.

[joshtriplett]

@bors r+

[bors]

📌 Commit e96a0a8 has been approved by joshtriplett