Skip to content

std: treat ENFILE as transient in the pidfd support probe#158486

Open
valentynkit wants to merge 1 commit into
rust-lang:mainfrom
valentynkit:pidfd-enfile-transient
Open

std: treat ENFILE as transient in the pidfd support probe#158486
valentynkit wants to merge 1 commit into
rust-lang:mainfrom
valentynkit:pidfd-enfile-transient

Conversation

@valentynkit

@valentynkit valentynkit commented Jun 27, 2026

Copy link
Copy Markdown
Contributor

The pidfd support probe special-cases EMFILE from pidfd_open: it returns the
error without caching anything, so the next spawn re-probes. ENFILE falls
through instead, into the fallback arm, so the probe caches pidfd as unsupported
for the rest of the process, even after descriptors free up.

Both errnos come from the same pidfd_open call and mean the same thing: the
process is out of file descriptors, just per-process (EMFILE) vs system-wide
(ENFILE). I don't see a reason to treat them differently here, so this handles
ENFILE the same way:

Err(e) if matches!(e.raw_os_error(), Some(libc::EMFILE | libc::ENFILE)) => {

I kept the raw raw_os_error() check rather than ErrorKind::TooManyOpenFiles
(#158326, which maps both) to match the rest of this probe, but can switch if
you'd prefer.

I didn't add a test, since triggering it needs real fd exhaustion during the
probe, which isn't practical to reproduce. The EMFILE arm isn't tested either.

r? libs

The probe handles EMFILE (per-process fd limit) as a transient error and re-probes later, but lets ENFILE (system-wide fd limit) fall through to the catch-all arm meant for an old kernel without pidfd support, which permanently caches the pidfd path as unsupported. ENFILE is the same transient condition, so handle both.
@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 27, 2026
@rustbot rustbot added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Jun 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants