Page MenuHomeFreeBSD

Add a pdvfork system call.

Authored by theraven on Jul 10 2021, 4:25 PM.
Referenced Files
Unknown Object (File)
Sat, Nov 11, 6:33 PM
Unknown Object (File)
Oct 10 2023, 5:29 PM
Unknown Object (File)
Jun 24 2023, 5:10 AM
Unknown Object (File)
Jun 24 2023, 4:24 AM
Unknown Object (File)
May 4 2023, 9:19 AM
Unknown Object (File)
May 3 2023, 5:31 PM
Unknown Object (File)
Mar 16 2023, 12:18 PM
Unknown Object (File)
Feb 15 2023, 9:43 PM


Group Reviewers

Currently, if you wish to make use of process descriptors then you must
use fork and incur the full CoW overhead for the child process, even if
it intends to call execve immediately.

This patch refactors the fork / vfork / pdfork implementations (which
included a lot of copied and pasted logic) into a single function and
implements wrappers for all four combinations of {fork, vfork} behaviour
combined with {fork, pdfork} output types.

Diff Detail

rS FreeBSD src repository - subversion
Lint Passed
No Test Coverage
Build Status
Buildable 40431
Build 37320: arc lint + arc unit

Event Timeline

@brooks, this should also be useful for combining CHERI coprocesses with Capsicum (coprocesses are currently created with vfork + coexecve).

pdfork(2) already takes flags, adding PD_VFORK is much better IMO than adding yet another syscall. I think it should go by the route of duplicating needed rfork(2) flags.

Can you split addition of do_pdvfork() vs. pdvfork/PD_VFORK introduction?

I had another note, to not include generated files into review and commit, but if you do PD_VFORK, this is resolved automatically.

This functionality clearly fills a gap, but the provided interface is too low level for applications to call. The code in lib/libc/gen/posix_spawn.c uses various non-standard facilities to handle things like signals correctly. Depending on how this is planned to be used, additional libc code may be useful, but it need not be part of this review.

Of the non-standard facilities used by posix_spawn(), RFSPAWN is a flag for the rfork syscall. It prevents running any signal handler function inherited from the parent and equivalent functionality should probably be added to pdvfork.


This needs __returns_twice like vfork/rfork/setjmp. If a PD_VFORK flag is added to pdfork() instead of adding pdvfork(), then pdfork() will need to be annotated.


The standard syscall stub will not work properly on x86 for this function. The child process pops the return address off the stack and if it is subsequently overwritten, the parent process will jump to nowhere. See for example lib/libc/amd64/sys/vfork.S.


Note that this patch does not even add the proposed syscall to libc/sys/Symbol.ver.

theraven added a subscriber: jhb.

Abandoning: This is probably not the right approach and @jhb is working on something similar so I'll wait for his version.