Skip to content

fix(orch): uffd handle no such process #2352

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
jakubno wants to merge 3 commits into
base: main
Choose a base branch
from
+10 −0
Draft

fix(orch): uffd handle no such process #2352

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
3332533
fix(orch): uffd handle no such process
jakubno Apr 10, 2026
9383371
chore: improve comment
jakubno Apr 10, 2026
14431b3
Update packages/orchestrator/pkg/sandbox/uffd/userfaultfd/userfaultfd.go
jakubno Apr 13, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions packages/orchestrator/pkg/sandbox/uffd/userfaultfd/userfaultfd.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -363,6 +363,15 @@ func (u *Userfaultfd) faultPage(
return nil
}

if errors.Is(copyErr, unix.ESRCH) {
// The process that triggered the fault no longer exists — FC was killed
// or crashed while the page fetch was in flight. This is expected during
// sandbox teardown; treat it as benign.
Copy link
Copy Markdown

@claude claude bot Apr 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Skipping onFailure (i.e. SignalExit) here changes the loop exit path for full-FC-death scenarios.

With the old code, any copyErr called SignalExit -> the exitFd pipe became readable -> the poll loop exited cleanly at the hasEvent(exitFd.Revents, unix.POLLIN) check.

With this change, when ESRCH means the entire FC process is gone, the loop now relies on the UFFD fd itself signalling completion. Looking at the serve loop (lines 154-175), POLLHUP on the UFFD fd is only tracked as a metric and continued -- the loop does not exit on POLLHUP alone. If the kernel sets only POLLHUP (not POLLIN) when FC's mm is released, the loop will busy-spin indefinitely until fdExit.Close() is called by external teardown code.

For the case this fix targets -- a single vCPU thread dying mid-fault while the rest of FC is still alive -- skipping SignalExit is correct. But the comment says FC was killed or crashed, implying full-process death. For that case, the clean exit now depends on either (a) external teardown always calling fdExit.Close() before this path is hit, or (b) the UFFD fd becoming readable (POLLIN + read error) after the mm is released. Given the existing TODO at line 167 about incomplete POLLHUP handling, it is worth verifying (a) is always guaranteed in the crash path.

u.logger.Debug(ctx, "UFFD serve copy error: process no longer exists", zap.Error(copyErr))

return nil
}

if copyErr != nil {
var signalErr error
if onFailure != nil {
Expand Down
Loading