Repository navigation
Conversation
Since Linux 6.16 (commit 8cf4b738f6d8, "pidfd: improve uapi when task isn't found"), pidfd_open() returns ENOENT instead of EINVAL when the pid exists but is not a thread-group leader. libcrun_kill_linux() only checked the pid with libcrun_check_pid_valid() for EINVAL, so on newer kernels it returned "open pidfd: No such file or directory" when the container's recorded pid had been reused by a thread of another process. "crun delete --force" then failed for that stopped container, and it could never be deleted. On a busy node, where the pid space wraps quickly, stopped containers accumulate. Handle ENOENT the same way as EINVAL: check that the pid still belongs to the container, and report ESRCH when it does not. Accept ENOENT in the same place in container_delete_internal(). Signed-off-by: Jonathan Siegel <jonathan@xenon.io>
|
Ephemeral COPR build failed. @containers/packit-build please check. |
Member
|
the patch LGTM but I am not sure we need the new test, we don't need to test the kernel |
usiegj00
force-pushed
the
pidfd-open-enoent
branch
from
October 21, 2026 14:48
4bc999d to
7e17b33
Compare
Author
|
Dropped the test. It was illustrative, and it made the pid reuse deterministic The PR is now the fix alone. |
kolyshkin
reviewed
Oct 21, 2026
Comment on lines
+8073
to
+8077
| /* Check if the PID is valid before reporting an error. pidfd_open | ||
| fails for a pid that is not a thread-group leader, for example when | ||
| the container's pid was reused by a thread: with EINVAL before | ||
| Linux 6.16, with ENOENT since (commit 8cf4b738f6d8, "pidfd: improve | ||
| uapi when task isn't found"). */ |
Collaborator
There was a problem hiding this comment.
this is way too long, enough to have something like
/* pidfd_open returns EINVAL (ENOENT since Linux 6.16) if the pid is
not a thread-group leader. Check if the PID is valid before
reporting an error. */
kolyshkin
requested changes
Oct 21, 2026
Collaborator
|
closing in favor of #2402 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Supersedes #2394, which was closed. @usiegl00 opened that PR with these same
commits; @giuseppe asked that the commit author and DCO match the submitting
account, so I am resubmitting under my own. @kolyshkin's review note on the
comment wording is already folded in, and the test has since been dropped per
@giuseppe's review below.
In commit 8cf4b738f6d8, "pidfd: improve uapi when task isn't found",
pidfd_open() returns ENOENT instead of EINVAL when the pid exists but is not
the leader of a thread-group. ENOENT is returned from Linux 6.16 onwards.
This happens when the pid space wraps under significant pid churn.
libcrun_kill_linux() only called libcrun_check_pid_valid() for EINVAL, so on
newer kernels
crun delete --forcefailed with "open pidfd: No such file ordirectory" and the stopped container could never be removed. On a busy node
these accumulate.
The fix treats ENOENT the same as EINVAL: check that the pid still belongs to
the container, and report ESRCH when it does not.
Verified in production on kernel 7.0 with a 1.25.1 backport: a delete that had
been failing succeeded, and pidfd_open errors went from roughly 4/min to 0.