This will always sleep at least once, so it's a slow path by definition.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
In principle this should work.
Testing requires the functional testing for vfork(2) behavior, and not the stress testing. In particular, you need to ensure that the parent of vfork is suspended, and only continue executing on child doing exec(2) or exit(2). There might be already some tests in the tree, I am not sure.
sys/kern/kern_fork.c | ||
---|---|---|
491 | != 0 | |
sys/kern/subr_trap.c | ||
262 | __predict_false does not make much sense there. |
Comment Actions
I've tried to write a test program, like this:
#include <err.h> #include <stdio.h> #include <stdbool.h> #include <stdlib.h> #include <unistd.h> volatile bool child_done; int main(void) { pid_t pid; child_done = false; pid = vfork(); if (pid < 0) err(1, "vfork"); if (pid > 0) { if (!child_done) errx(1, "child not done"); exit(0); } child_done = true; exit(0); }
... and then I've tested if the test works by breaking the kernel, by ifdefing out the call to fork_rfppwait(). Turns out this results in a _very_ broken system, it seems everything that calls vfork(2) segfaults, which makes sense, because of the stack. Does that count as tested enough? :-)