test(uffd): unregister UFFD range before fd close in cross-process cleanup#2476
test(uffd): unregister UFFD range before fd close in cross-process cleanup#2476ValentaTomas merged 1 commit intomainfrom
Conversation
…eanup Add an unregister() helper around UFFDIO_UNREGISTER and call it from the late cmd.Wait() cleanup in configureCrossProcessTest, before the early uffdFd.close() cleanup runs (cleanups are LIFO). Today this is a no-op: no test enables UFFD_FEATURE_EVENT_REMOVE, so the kernel never queues REMOVE events that could keep munmap blocked on un-acked events against a registered range. Pulling this out as its own small change so the upcoming PR that does enable REMOVE events doesn't silently bring along a behavioural test-cleanup change too.
PR SummaryLow Risk Overview Reviewed by Cursor Bugbot for commit a0522c3. Bugbot is set up for automated code reviews on this repo. Configure here. |
There was a problem hiding this comment.
LGTM — test-only, no production code changes, and the cleanup ordering logic is correct.
Extended reasoning...
Overview
Changes are confined to two _test.go files in packages/orchestrator/pkg/sandbox/uffd/userfaultfd/. Adds an unregister() helper wrapping UFFDIO_UNREGISTER (mirroring the existing register() pattern) and calls it in the LIFO cleanup chain before uffdFd.close().
Security risks
None. These are test helpers with no impact on production paths, authentication, or data handling.
Level of scrutiny
Low. The diff is +23/-0 in test files only, mechanically mirrors the existing register() implementation, and is currently a no-op (no test enables UFFD_FEATURE_EVENT_REMOVE). The LIFO ordering reasoning is sound and well-documented.
Other factors
No bugs found, no outstanding reviewer concerns to address. The preparatory-PR rationale (isolating cleanup logic from the follow-up REMOVE-handling change) is sensible engineering hygiene.
Summary
Split out from the
feat/free-page-reportingbranch as a small, standalone preparatory PR.unregister()helper infd_helpers_test.gothat wrapsUFFDIO_UNREGISTER.Why now (and why it's safe to land alone)
Today this is a no-op: no test enables `UFFD_FEATURE_EVENT_REMOVE`, so the kernel never queues REMOVE events that could keep `munmap` blocked on un-acked events against a still-registered range.
Once the follow-up REMOVE-handling PR enables that feature, missing this cleanup would manifest as flaky hangs in test teardown rather than as an obvious failure. Landing the cleanup first means that follow-up PR doesn't silently bring along a behavioural test-cleanup change alongside the production logic.
Diff
`+23 / -0` across 2 files, both `_test.go`.
Test plan