Skip to content

Conversation

@mheon
Copy link
Member

@mheon mheon commented Sep 4, 2025

Plus release notes

Does this PR introduce a user-facing change?

NONE

mheon and others added 4 commits September 4, 2025 13:54
We already used `x` in tmpfiles, to ensure systemd did not remove
our directories or clean their contents (we really need them to
be left unmodified). However, systemd-tmpfiles lets us use more
than one directive per line, which means we can safely add an R!
(recursive remove on reboot) to these lines to ensure that, if
/tmp is not a tmpfs, systemd-tmpfiles will still remove our
temporary files, ensuring reboots are still accurately detected.

Signed-off-by: Matt Heon <[email protected]>
The `cleanupExecBundle` function was only meant to be called on a
locked container, as it does some state mutation operations. It
also has a timed wait (if the directory is busy and can't be
removed yet, give it a few milliseconds) in which it deliberately
yields the lock to not block the container for that time.

The `healthCheckExec()` function calls `cleanupExecBundle` out of
a `defer` block. This is after the `defer c.lock.Unlock()` so it
fires afterwards when the function returns, so we're normally
fine - the container is still locked when our defer runs. The
problem is that `healthCheckExec()` also unlocks the container
during the expensive exec operation, and can actually fail and
return while not holding the lock - meaning our `defer` can fire
on an unlocked container, leading to a potential double unlock
in `cleanupExecBundle`.

We could, potentially, re-lock the container after the exec
occurs, but we're actually waiting for a `select` to trigger to
end the function, so that's not a good solution. Instead, just
re-lock (if necessary) in the defer, before invoking
`cleanupExecBundle()`. The `defer c.lock.Unlock()` will fire
right after and unlock after us.

Fixes containers#26968

Signed-off-by: Matthew Heon <[email protected]>
@openshift-ci openshift-ci bot added release-note-none approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Sep 4, 2025
Copy link
Member

@Luap99 Luap99 left a comment

Choose a reason for hiding this comment

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

LGTM

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Sep 4, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Luap99, mheon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@baude
Copy link
Member

baude commented Sep 4, 2025

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Sep 4, 2025
@TomSweeneyRedHat
Copy link
Member

LGTM
only one possible suggestion for consideration, do you want to mention the CVE and/or the ulinkunitz/xz to v0.5.12 bump in the release notes?

@mheon
Copy link
Member Author

mheon commented Sep 4, 2025

Naw, I don't think it's necessary. We're quite sure it doesn't affect us.

@openshift-merge-bot openshift-merge-bot bot merged commit 75c78eb into containers:v5.6 Sep 4, 2025
84 of 88 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. release-note-none

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants