resource: release process slots on exit, not on wait

[congwang-mk]

Fixes #229.

Problem

The process limit took a slot when a fork was allowed, but freed it when a blocking wait4/waitid was entered, on the assumption that such a wait reaps exactly one child. Entering a wait is neither necessary nor sufficient for a process going away, so the count drifted in both directions.

Reproduced on main (0.8.8):

Case	Limit	Result
Children reaped with WNOHANG (the report)	50	fork 50 fails with EAGAIN
SIGCHLD set to SIG_IGN, kernel auto-reaps	10	fork 10 fails
Double fork, orphans reaped by init	10	fork fails after about 10 rounds
Blocking waitpid(1, 0) (ECHILD) before each fork	10	40 live children (bypass)
Raw fork(2) syscall on x86_64	5	30 live children (bypass)

The first three make the limit a lifetime fork budget, which is what the reporter hit with a long-lived agent. The last two let a sandbox run past the limit. Raw fork(2) was never counted because it was only notified when argv safety was required; glibc's fork() is clone(2), so ordinary programs never showed it.

Fix

Three commits:

1. Count bare fork(2). It is now notified unconditionally, so every process creation reserves a slot.
2. Release slots on exit, not on wait. The pidfd exit watcher frees the slot, exactly once per process, through a slot table in ProcessIndex keyed by PidKey. A pidfd turns readable however the process dies, so _exit, signals and the OOM killer are all covered. The slot belongs to the thread-group leader, so registering a thread also registers its leader.

Two gaps had to be closed for exit-based release to work:

• A child that forks and exits without any notified syscall was never registered. exit and exit_group are now notified, so it registers on its way out while pidfd_open still succeeds.
• The watcher runs asynchronously, so a parent that reaps a child and forks again at once could beat it. handle_fork polls the slot-holding pidfds before refusing a fork. The kernel marks the pidfd readable before the parent can observe the death, so this is deterministic.

handle_wait, its dispatch entry and the BPF carve-outs for non-blocking waits are removed. No ptrace, user namespace or cgroup is involved.

3. Make the limit opt-in. max_processes was the only resource limit on by default (64); memory, open files, CPU and disk are unlimited unless set. It is now an Option, None meaning unlimited, which is what the issue asked for. Unset also stays clear of the known limits below. The supervisor uses u32::MAX internally, since 0 is a valid runtime restriction. A zeroed MaxProcesses in Go now means unlimited, the same as a zeroed MaxMemory. Fork notification is unchanged (namespace flag denial, checkpoint freeze and policy_fn need it). A default sandbox no longer contains a fork bomb; the reference docs say so.

Known limits

• A child killed by a signal before it makes any notified syscall is never registered, so its slot leaks. The window is small (openat, close, socket, clone are always notified) and the leak only pushes the count up, so it cannot be used to get past the limit.
• A fork the kernel rejects after Continue (ENOMEM, host RLIMIT_NPROC) also leaks a slot, as it did before.
• Zombies no longer count against the limit, since the slot is freed at exit rather than at reap.

Tests

• New integration tests in test_resource.rs, each forking more children in sequence than the limit allows at once: WNOHANG reaping, SIGCHLD auto-reap, orphaned grandchildren, concurrent short-lived children, the ECHILD wait loop (must stay at the limit), and raw fork(2). The WNOHANG, auto-reap, orphan and ECHILD tests failed before the fix.
• The existing blocking-wait test now runs with no headroom (max_processes=2), which exercises the at-limit pidfd poll.
• test_process_limit_unset_is_unlimited holds 100 live children in a sandbox with no limit set.
• Locally: all Rust workspace lib and integration suites pass in release mode with one test thread (771 lib, 445 integration); Python test_policy_fn.py, test_sandbox.py, test_sandbox_config.py and test_profile.py pass (200); Go tests pass. The exit-accounting tests passed 36 consecutive runs. The rest of the Python suite was not run locally.

🤖 Generated with Claude Code