Page MenuHomeFreeBSD

kern: factor `fork1()` allocation into `fork_alloc_proc`
Needs ReviewPublic

Authored by inquire_JohnEricson.me on Thu, Aug 6, 4:06 AM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Aug 26, 7:19 PM
Unknown Object (File)
Wed, Aug 26, 5:05 PM
Unknown Object (File)
Wed, Aug 26, 6:16 AM
Unknown Object (File)
Tue, Aug 25, 11:00 PM
Unknown Object (File)
Tue, Aug 25, 4:03 PM
Unknown Object (File)
Tue, Aug 25, 4:00 PM
Unknown Object (File)
Mon, Aug 24, 8:13 PM
Unknown Object (File)
Sun, Aug 23, 9:05 PM
Subscribers

Details

Reviewers
markj
glebius
kib
Summary

Factor the process and thread allocation out of fork1 into
fork_alloc_proc: proc/thread allocation, credentials, RACCT, MAC,
and the process-count limit checks (nprocs/maxproc, RLIMIT_NPROC).

This is preparation for adding a second consumer of this logic: the
pdnew family of syscalls implementing the process creation model
proposed in
https://lists.freebsd.org/archives/freebsd-arch/2022-January/000140.html

Not a pure refactor. fork1 interleaves the process-descriptor and
address-space allocation (procdesc_falloc, vmspace_fork,
swap_reserve) in the middle of the sequence that fork_alloc_proc
now bundles, so the nprocs/maxproc and chgproccnt (RLIMIT_NPROC)
checks move relative to those steps. This is observable only under
simultaneous resource exhaustion: the errno returned when both the
per-user process limit and swap are exhausted may change (EAGAIN vs
ENOMEM), and on the RFPROCDESC path a process-descriptor fd is briefly
allocated before the maxproc check. Both outcomes are benign.

Bundling the checks into the shared helper is deliberate: it keeps the
rarely-exercised second consumer (pdnew) on exactly the same,
well-tested allocation path as ordinary fork, rather than a
lightly-tested clone.

Note: This patch series overall is very big, more than I feel competent
reviewing, so I feel a bit ill-mannered submitting it yet. Certainly,
everyone should feel free to ignore it until my "unix socket connectat"
series is landed. I am submitting it now anyway simply because I think
the end functionality is very cool, and I don't want it to grow dusty on
my machine.

Assisted-by: Claude Code (Claude Opus 4.8/5 and Fable 5)

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 75409
Build 72292: arc lint + arc unit