(RHEL-144833) generator: order cryptsetup/verity/integrity after systemd-udevd - #165
Closed
siteshwar wants to merge 2 commits into
Closed
(RHEL-144833) generator: order cryptsetup/verity/integrity after systemd-udevd#165siteshwar wants to merge 2 commits into
siteshwar wants to merge 2 commits into
Conversation
github-actions
Bot
changed the title
Commit validationTracker - RHEL-144833 The following commits meet all requirements
Tracker validationSuccess馃煝 Tracker RHEL-144833 has set desired product: Pull Request validationFailed馃敶 Review - Missing review from a member (1 required) Success馃煝 CI - All checks have passed Triggered by Workflow Run |
Otherwise, queued uevents may be lost on soft-reboot. Similar to f89985c, but for systemd-udevd. (cherry picked from commit 0d1819e791a97367c2c0cead738111cfcc1e7491) Related: RHEL-144833
During soft-reboot teardown, systemd-cryptsetup@.service's ExecStop runs
libcryptsetup's crypt_deactivate(), which issues DM_REMOVE with a udev
cookie and blocks in dm_udev_wait() until 95-dm-notify.rules decrements
the cookie semaphore via "dmsetup udevcomplete $env{DM_COOKIE}".
The generated cryptsetup unit had only After=systemd-udevd-kernel.socket,
not After=systemd-udevd.service. The .socket has IgnoreOnIsolate=yes and
is not stopped during soft-reboot, so it provides no ordering at all for
the service teardown. Meanwhile systemd-udevd.service has
Conflicts=soft-reboot.target (added in 0d1819e791) and stops as soon as
soft-reboot.target starts, with no ordering relative to cryptsetup's
ExecStop.
Once udevd's device monitor event source is disabled in manager_exit(),
pending DM_REMOVE uevents are no longer processed and the cookie
semaphore stays at 1 forever, blocking soft-reboot at "Stopping
Cryptography Setup..." until JobTimeoutSec=30min on soft-reboot.target
fires.
Add systemd-udevd.service to the After= ordering of the generated
cryptsetup, veritysetup and integritysetup units. By systemd's job
ordering rules (job_compare() in src/core/job.c), when two units are
both being stopped and one has After= the other, the After= unit is
stopped first. So with cryptsetup@*.service After=systemd-udevd.service,
cryptsetup stops first (cookie acknowledged by the still-live udevd),
then udevd stops.
Putting After=umount.target on systemd-udevd.service does not work: at
soft-reboot, udevd's stop job runs concurrently with umount.target's
start job, and JOB_STOP unconditionally precedes JOB_START in the
transaction (see src/core/job.c:1742). The ordering has to be expressed
between two stop jobs, which is what putting After=systemd-udevd.service
on the dm consumers achieves.
Fixes: #40298
(cherry picked from commit 66a0bdad4f03f0c260ea2ba409f7b7c3884309fe)
Resolves: RHEL-144833
Author
|
I tried to reproduce this issue on |
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
4 participants
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.
During soft-reboot teardown, systemd-cryptsetup@.service's ExecStop runs libcryptsetup's crypt_deactivate(), which issues DM_REMOVE with a udev cookie and blocks in dm_udev_wait() until 95-dm-notify.rules decrements the cookie semaphore via "dmsetup udevcomplete $env{DM_COOKIE}".
The generated cryptsetup unit had only After=systemd-udevd-kernel.socket, not After=systemd-udevd.service. The .socket has IgnoreOnIsolate=yes and is not stopped during soft-reboot, so it provides no ordering at all for the service teardown. Meanwhile systemd-udevd.service has Conflicts=soft-reboot.target (added in 0d1819e791) and stops as soon as soft-reboot.target starts, with no ordering relative to cryptsetup's ExecStop.
Once udevd's device monitor event source is disabled in manager_exit(), pending DM_REMOVE uevents are no longer processed and the cookie semaphore stays at 1 forever, blocking soft-reboot at "Stopping Cryptography Setup..." until JobTimeoutSec=30min on soft-reboot.target fires.
Add systemd-udevd.service to the After= ordering of the generated cryptsetup, veritysetup and integritysetup units. By systemd's job ordering rules (job_compare() in src/core/job.c), when two units are both being stopped and one has After= the other, the After= unit is stopped first. So with cryptsetup@*.service After=systemd-udevd.service, cryptsetup stops first (cookie acknowledged by the still-live udevd), then udevd stops.
Putting After=umount.target on systemd-udevd.service does not work: at soft-reboot, udevd's stop job runs concurrently with umount.target's start job, and JOB_STOP unconditionally precedes JOB_START in the transaction (see src/core/job.c:1742). The ordering has to be expressed between two stop jobs, which is what putting After=systemd-udevd.service on the dm consumers achieves.
Fixes: #40298
(cherry picked from commit 66a0bdad4f03f0c260ea2ba409f7b7c3884309fe)
Resolves: RHEL-144833