Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
syscall: use of CLONE_VFORK is scary #20732
Commit 9e6b79a (not yet released) switched to using
I don't have a specific flaw in mind, and it's possible there isn't one right now. But, for example, if the compiler reused named stack slots (which it doesn't, but certainly could), it would be easy for the after-fork child code to corrupt the local variables later used by the parent's after-fork path.
There isn't much code in the parent's after-fork path, but there isn't none. There absolutely have to be comments saying what can and can't be done, if nothing else.
A robust solution would be for the assembly implementation of
I fully agree. Like it said earlier when proposing this change, I am by far not an expert on the matter. I saw the serious performance issues and found this solution by reading about the problem space. I'm all for improving this if necessary.
Question: If we would put the call to
That's a good idea. If the caller of
This certainly won't get inlined right now, but in the spirit of making this more robust, we have to disable inlining because inlining would defeat the purpose of separating forkAndExecInChild1 into a separate function. Updates #20732. Change-Id: I736c3f909cc42c5f5783740c2e19ba4827c7c2ec Reviewed-on: https://go-review.googlesource.com/46174 Run-TryBot: Austin Clements <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com> Reviewed-by: Brad Fitzpatrick <firstname.lastname@example.org>