You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(rootfs/qemu-static): close 2 more races flagged by codex review of 3d4c8cd
Codex re-review of fix2 (commit 3d4c8cd) confirmed the original three
races are properly closed but identified two new ones, both producing
the same class of runtime failure: a parallel builder ends up running
chroot exec against globally-enabled qemu-arm with no qemu binary
inside its chroot.
1. Disable-failure path left a live owner. When 'echo 0 > qemu-arm'
itself fails (no CAP_SYS_ADMIN), fix2 chose to leave the owner lock
and the prior-state file in place, on the theory that the cleanup
handler would no-op the restore at exit. But the owner stays
counted as live for the entire build duration, so a concurrent
builder enters its own setup, sees live_count > 1, takes the join
branch, skips qemu binary deployment, and fails at chroot exec
time. Fix: a failed disable now performs a full abort under the
held control lock — rm state file, release owner, drop control,
return 1. The aborted setup leaves no observable native window for
anyone to join.
2. Join path did not verify the actual kernel state. fix2 trusted that
live_count > 1 implies qemu-arm is disabled. But an external agent
(admin running 'update-binfmts --enable qemu-arm', a stray service)
can flip it back on during the active window. Our pre-flight
arch-test then passes as a false positive — qemu interprets the
ARM stub — and we skip qemu binary deployment, hitting the same
runtime failure as case 1. Fix: in the join branch, observe the
current qemu-arm state explicitly. If it is enabled, this is not
a normal join — abort to qemu fallback with a warning naming the
external mutator. This is a one-shot invariant check at join time,
not a periodic re-verify (which codex previously argued against).
Reported-by: codex (PR #9769 lock-impl re-review)
Assisted-by: Claude:claude-opus-4.7
Signed-off-by: Igor Velkov <325961+iav@users.noreply.github.com>
display_alert "Native armhf via binfmt_elf""${live_count} live owner(s) but qemu-arm is observably enabled (external agent re-enabled it); aborting join, falling back to qemu-arm-static emulation""wrn"
342
+
_native_armhf_release_owner_lock
343
+
exec {control_fd}>&-
344
+
return 1
345
+
fi
346
+
# Cleanup is still registered so this owner's release decrements
display_alert "Native armhf via binfmt_elf""joining ${live_count} existing native-armhf owner(s); shared qemu-arm state preserved""info"
306
350
fi
@@ -311,13 +355,13 @@ function _native_armhf_setup_binfmt_elf() {
311
355
# arm64-compat-vdso, PR #9284) — qemu-arm interprets the stub.
312
356
if! arch-test armhf > /dev/null 2>&1;then
313
357
display_alert "Native armhf via binfmt_elf""post-disable verification failed (host kernel lacks COMPAT_VDSO — see extensions/arm64-compat-vdso); restoring and falling back to emulation""wrn"
314
-
# Restore is via cleanup handler when owner_lock releases. Mark
315
-
# ourselves as not-owner-of-native-mode so the cleanup invocation
316
-
# that runs immediately on this return path triggers restore.
358
+
# Drop control lock so the handler can re-acquire it. Do NOT
359
+
# release the owner lock here — the handler must release it UNDER
360
+
# control so live_count reflects only OTHER owners and the
361
+
# state-preserving restore decision uses a consistent snapshot.
362
+
# Releasing owner outside the control section was the race codex
363
+
# flagged in the previous round.
317
364
exec {control_fd}>&-
318
-
_native_armhf_release_owner_lock
319
-
# Manually invoke the same restore path so the failed setup leaves
320
-
# binfmt_misc as we found it; subsequent owners (if any) re-evaluate.
321
365
trap_handler_native_armhf_restore_qemu_arm
322
366
return 1
323
367
fi
@@ -344,22 +388,30 @@ function _native_armhf_release_owner_lock() {
344
388
# disabled state. Restore writes the prior state observed at first-owner
0 commit comments