Page MenuHomeFreeBSD

posix_spawn(): create a guard page below the stack for rfork_thread
ClosedPublic

Authored by kib on Jun 29 2026, 10:10 PM.
Tags
None
Referenced Files
F168169661: D57955.id180961.diff
Wed, Aug 26, 5:00 PM
F168169622: D57955.id180961.diff
Wed, Aug 26, 5:00 PM
F168169160: D57955.id180955.diff
Wed, Aug 26, 4:57 PM
F168153156: D57955.id180961.diff
Wed, Aug 26, 3:12 PM
F168142007: D57955.id.diff
Wed, Aug 26, 1:57 PM
F168130801: D57955.diff
Wed, Aug 26, 12:46 PM
F168107340: D57955.id180955.diff
Wed, Aug 26, 10:27 AM
Unknown Object (File)
Mon, Aug 24, 11:36 AM
Subscribers

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

lib/libc/gen/posix_spawn.c
306

What would prevent us from being able to map over the guard here? I wonder if this should be an assert instead.

kib marked an inline comment as done.Jun 29 2026, 10:48 PM

The cost is +3 syscalls per spawn, but so be it.

lib/libc/gen/posix_spawn.c
306

I dislike asserts in libraries. It is not the library authors to establish the assert policy for the caller.

The check is mostly for correctness. If I somehow missed the correct args to mmap, I can see it immediately.

In D57955#1328646, @kib wrote:

The cost is +3 syscalls per spawn, but so be it.

I think it's defensible for the benefit of the guard page. Worst case scenario, we add a small pool of free stacks to choose from if we get complaints? A little bit of additional complexity, but not terrible.

lib/libc/gen/posix_spawn.c
306

Right, but in this case we're presumably hiding a kernel bug if it does actually fail at this particular point, which feels like a reasonable exception to make for assertions in libraries. I don't insist either way, though.

This revision is now accepted and ready to land.Jun 29 2026, 11:01 PM