Deprecate vfork

[Amanieu]

The compiler may generate incorrect code for vfork and setjmp because they are missing the #[returns_twice] attribute which is currently unstable (tracking issue). Since vfork is impossible to use safely, I propose deprecating it until #[returns_twice] is stable.

[rust-highfive]

r? @gnzlbg

(rust_highfive has picked a reviewer for you, use r? to override)

[gnzlbg]

@Amanieu thank you for filling this PR.

Right now, because vfork is lacking the returns_twice attribute, the compiler might mis-compile user code in some cases. Do we have any reported mis-compilations (or MWEs) due to this that illustrate the issue?

Claiming that this feature is impossible to use correctly won't do much for users that are already using vfork, because if it works for them, then in their eyes, it can be used correctly, and also, there is no really an alternative available, so they will just turn the warning off.

So what do we want to achieve ?

I think the best we can do right now is document any known mis-compilations by filling an issue, and then use the deprecation warning to inform users that such known mis-compilations exist, and that there is a nightly feature that they can use to avoid them, but that they are kind of on their own for now.

Just telling them "don't use this" without telling them "what to use instead" produces a very frustrating user experience. If this is really always impossible to use correctly, we should at least point them to an issue that explains that in detail.

[Amanieu]

I haven't managed to create a miscompiling example, but essentially, if the compiler decides to perform tail call optimization in the vfork child, this will corrupt the entire stack frame for the parent as well.

[Amanieu]

Alternatively, the compiler could decide to share a single stack slot for 2 variables, one in the parent and one in the child since it "knows" that only one of the two branches is taken, not both.

[gnzlbg]

I think maybe @comex had an actual mis compilation example for a lack of returns_twice attribute but I can find it. There is an issue open in the rfc repo for longjmp, maybe we could link there ? I'd prefer to avoid using the term "impossible", but I think the deprecation warning can be a bit longer and strongly suggest not to use this API and being clear that it is UB and that any new toolchain upgrade could break existing "working" code in subtle ways silently so using it is very dangerous.

[Amanieu]

I've managed to create a miscompilation example: https://play.rust-lang.org/?version=nightly&mode=release&edition=2018&gist=e192ab81e8d408fa9984f766e2356697

As you can see, variables modified in the vfork child cause unrelated variables in the parent to be modified.

[Amanieu]

However if you add #[ffi_returns_twice] then the issue no longer appears: https://play.rust-lang.org/?version=nightly&mode=release&edition=2018&gist=0de019e56b69aa048f3e0f5319cc187e

[Amanieu]

@gnzlbg ping?

[gnzlbg]

This looks good to me @Amanieu. CI is red due to unrelated issues, but I'll merge it ASAP.

In the mean time, could you create an issue in this repo explaining the problem with those links, and add a link to it to the deprecation message ?

[Amanieu]

Added a reference to #1596 in the deprecation message.

[gnzlbg]

Thanks, as soon as we get up bors working again for the repo I'll start merging PRs.

[gnzlbg]

@bors: r+

[bors]

📌 Commit 1f7352c has been approved by gnzlbg

[bors]

⌛ Testing commit 1f7352c with merge a13ad69...

[bors]

☀️ Test successful - checks-cirrus-freebsd-10, checks-cirrus-freebsd-11, checks-cirrus-freebsd-12, status-azure
Approved by: gnzlbg
Pushing a13ad69 to master...

[sporksmith]

For anyone else who finds themselves here from the "vfork is deprecated" documentation - I have a working proof-of-concept workaround that calls vfork and exec from inline assembly on Linux x86-64. https://github.com/sporksmith/dev-journal/blob/main/rust-vfork/src/main.rs

The idea is that since both are done in assembly, the Rust compiler doesn't see the second return.

Similarly, I think this could alternatively be done by calling out to a helper C function that calls vfork and exec.

EDIT: I started thinking about whether this could be generalized into a utility function... and then realized that posix_spawn already does that. So probably better to just use posix_spawn in most cases, as long as it supports the actions that would otherwise need to perform in between the vfork and the exec.