[xalestar]

Intent: a guest RLIMIT_CPU limits the guest's CPU time as it does on Linux. This is follow-up 2 of #448, which stores the limit in the guest table and leaves it unenforced.

Failure fixed: on main, a guest that sets RLIMIT_CPU to 1 s and spins gets no signal and runs until the vCPU watchdog ends elfuse after 10 s with status 124. On Linux the guest gets SIGXCPU after 1 s of CPU time.

This PR follows check_process_timers (kernel/time/posix-cpu-timers.c). At the soft limit the process gets SIGXCPU and the soft limit rises by one second, so a process that catches or ignores SIGXCPU gets another one each CPU second. At the hard limit it gets SIGKILL; when soft equals hard, SIGKILL alone. A guest spinning at EL0 takes no exit where elfuse could check the limit, so rlimit_cpu_main samples the host process CPU time, the clock guest CLOCK_PROCESS_CPUTIME_ID reads, from a thread of its own. The thread starts on the first finite soft limit (boot seed, fork-child restore, or prlimit64) and sleeps for the remaining CPU time divided by the online CPU count, at least 10 ms. A limit change wakes it.

Review focus:

• rlimit_lock is a leaf, so the sampler drops it before signal_queue_info, which takes sig_lock.
• The soft limit is raised before SIGXCPU is queued, so a handler that calls getrlimit reads the new value, as on Linux.
• Both signals are queued as SI_KERNEL with si_pid 0, matching SEND_SIG_PRIV in check_rlimit.
• A fork child starts the sampler through sys_rlimit_cpu_start, called right after signal_set_state, since that call replaces the shared pending set and would drop a signal queued earlier.
• elfuse ignores host SIGXCPU and lifts its own RLIMIT_CPU soft limit to the hard one, as eeada5b does for RLIMIT_FSIZE. XNU sends nothing at the hard limit, so the sampler sends SIGKILL at the lower of the guest and host hard limits, which keeps a guest with euid 0 from raising its way past the host limit.

Known gaps: a fork child is a new host process, so its CPU time starts with what its elfuse process spent before the guest resumes (a fresh launch measured 6 to 17 ms), where a Linux child starts at 0. The signal can land up to 10 ms after the limit, the sampler's shortest sleep. A fatal default signal taken by a worker thread ends only that thread (#476), so the sampler sends SIGKILL again every 10 ms, and a default SIGXCPU taken by a worker is not sent again. Under a finite host RLIMIT_CPU hard limit, elfuse stalls before the guest runs, on main as well (#474), so the host hard limit is checked only with a build that reads it from the environment. A CLONE_VM child without CLONE_THREAD runs in its parent's host process, so the two share one CPU clock and the parent can be signalled for the child's CPU time (#478).

Verified on 8134b88, rebased onto 3347188: make check-format and make check pass; make test-matrix-elfuse-aarch64 gives 317 passed, 0 failed, 10 skipped.

[cubic-dev-ai]

3 issues found across 11 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="tests/test-rlimit-cpu.c">

<violation number="1" location="tests/test-rlimit-cpu.c:86">
P3: Use `volatile sig_atomic_t` for the state shared with `on_xcpu_late`; ordinary volatile `int`/`unsigned char` objects are not the signal-safe communication type and can make this timing test flaky or undefined.</violation>
</file>

<file name="tests/test-rlimit-seed.sh">

<violation number="1" location="tests/test-rlimit-seed.sh:107">
P2: This test can race the guest's initial one-second limit during elfuse startup. Ignore guest `SIGXCPU` before raising the limit, or otherwise prevent startup CPU from being charged, so a queued startup signal cannot terminate the test after `ulimit -S -t unlimited` runs.</violation>
</file>

<file name="src/main.c">

<violation number="1" location="src/main.c:563">
P2: This installs the host `SIGXCPU` ignore only after substantial startup work. A finite inherited `RLIMIT_CPU` can therefore kill elfuse during argument or sysroot setup before this line runs; move the registration to the start of `main()`.</violation>
</file>

<sub>Tip: Get a Slack DM when cubic finishes reviewing your PRs. Connect Slack

View guided diff | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: This test can race the guest's initial one-second limit during elfuse startup. Ignore guest SIGXCPU before raising the limit, or otherwise prevent startup CPU from being charged, so a queued startup signal cannot terminate the test after ulimit -S -t unlimited runs.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At tests/test-rlimit-seed.sh, line 107:

<comment>This test can race the guest's initial one-second limit during elfuse startup. Ignore guest `SIGXCPU` before raising the limit, or otherwise prevent startup CPU from being charged, so a queued startup signal cannot terminate the test after `ulimit -S -t unlimited` runs.</comment>

<file context>
@@ -97,6 +97,32 @@ else
+# writes to a file, since in a command substitution it would report the
+# subshell; the file case above is done with that file.
+# shellcheck disable=SC2016  # Expanded by the guest shell.
+SPIN_PAST_1S='ulimit -S -t unlimited || exit 1
+n=0
+while [ $n -lt 1000 ]; do
</file context>

Suggested change

	SPIN_PAST_1S='ulimit -S -t unlimited || exit 1
	SPIN_PAST_1S='trap : XCPU
	ulimit -S -t unlimited || exit 1

[cubic-dev-ai]

P2: This installs the host SIGXCPU ignore only after substantial startup work. A finite inherited RLIMIT_CPU can therefore kill elfuse during argument or sysroot setup before this line runs; move the registration to the start of main().

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At src/main.c, line 563:

<comment>This installs the host `SIGXCPU` ignore only after substantial startup work. A finite inherited `RLIMIT_CPU` can therefore kill elfuse during argument or sysroot setup before this line runs; move the registration to the start of `main()`.</comment>

<file context>
@@ -553,6 +553,15 @@ int main(int argc, char **argv)
+     * hard limit, so the RLIMIT_CPU sampler (sys.c) enforces both the guest
+     * limits and the host hard limit.
+     */
+    signal(SIGXCPU, SIG_IGN);
+
     /* Block the vCPU-preemption signals and start the sigwait thread before any
</file context>

[cubic-dev-ai]

P3: Use volatile sig_atomic_t for the state shared with on_xcpu_late; ordinary volatile int/unsigned char objects are not the signal-safe communication type and can make this timing test flaky or undefined.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At tests/test-rlimit-cpu.c, line 86:

<comment>Use `volatile sig_atomic_t` for the state shared with `on_xcpu_late`; ordinary volatile `int`/`unsigned char` objects are not the signal-safe communication type and can make this timing test flaky or undefined.</comment>

<file context>
@@ -0,0 +1,330 @@
+    spin();
+}
+
+static volatile unsigned char late_seen[8];
+static volatile int late_n;
+
</file context>

Suggested change

	static volatile unsigned char late_seen[8];
	static volatile int late_n;
	static volatile sig_atomic_t late_seen[8];
	static volatile sig_atomic_t late_n;

[jserv]

This case passes without exercising the fork-child start. signal_get_state copies the shared pending set into the snapshot and signal_set_state restores it, so the SIGXCPU the parent earned while blocked arrives already pending in the child. The child dies the moment it unblocks, and deleting the sys_rlimit_cpu_start call in fork_child_main leaves the test green.

Drain the pending signal in the parent before forking (sigtimedwait with a zero timeout), so the child inherits only the limit and has to be killed by its own sampler.

[jserv]

This failure exit comes after the fork was committed: the parent has already returned the child pid, and proc_lifecycle_sync_self has run. If pthread_create fails here, the guest sees a successful fork whose child exits 1 with no proc_process_exit record, where Linux would have failed the fork with EAGAIN.

Consider creating the sampler thread disarmed before the commit (next to sys_rlimit_restore) and having sys_rlimit_cpu_start only arm it. Then a thread-creation failure takes one of the existing pre-commit exits, and this call can no longer fail.

[jserv]

The send decision is made under rlimit_lock, but the signal is queued after the lock is dropped. A guest thread can complete prlimit64 in that gap (for example, raise the hard limit from 1 s to 10 s), and the sampler then queues a SIGKILL that the new limit would not have produced. Linux decides and queues under one lock.

The window is tiny, so this may be acceptable. If so, note it in the comment above rlimit_cpu_send_locked. Otherwise, re-check the limit after taking sig_lock and drop the signal if it no longer applies.