fix corner cases that allow stale properties on user slices - #33
Merged
Merged
Conversation
grondo
force-pushed
the
deviceallow-stale
branch
from
September 16, 2026 14:53
d34c297 to
f647fdc
Compare
Contributor
Author
|
Thanks! |
Contributor
Merge Queue Status
This pull request spent 3 minutes 50 seconds in the queue, with no time running CI. Waiting for
All conditions
ReasonHintYou may have to fix your CI before adding the pull request to the queue again. Requeued — the merge queue status continues in this comment ↓. |
Problem: When a user has multiple jobs on a node, and the last job that allocated any GPUs ends, the user slice could keep access to devices that are no longer allocated. This occurs because `set-property` only changes properties that are named, and the resource mapper may omit DeviceAllow entirely when no GPUs are allocated, so the previous list remains assigned to the slice. Always emit a bare "DeviceAllow=" ahead of the entries, which resets the list, so the slice ends up with just the devices computed for the jobs running now. It precedes them because a reset is order sensitive. Update the argument-splitting test, which asserts the full list of DeviceAllow arguments, for the added reset. Assisted-by: Claude:Opus-5
Problem: Nothing covers how a DeviceAllow list is reset, so a stale device left on the slice by an earlier update would not be caught. Add tests that modify_slice resets the list when the mapper grants no devices, and that the reset precedes the entries, since a reset after them discards them. Assisted-by: Claude:Opus-5
Problem: A user's login sessions can be held to a device policy set for a job that has already ended. set-property only changes the properties it names, so a DevicePolicy from an earlier update stays on the slice when a later one omits it. A mapper that leaves device access unrestricted does so by returning DevicePolicy=auto or omitting it. Omitting it after a job that set "closed" leaves the slice closed, so sessions in it are confined to the standard pseudo devices even though nothing asked for that. Emit DevicePolicy=auto alongside the DeviceAllow reset, ahead of the mapper's own properties, which override it when set. The default value is used rather than an empty one, which systemd rejects. Assisted-by: Claude:Opus-5
Problem: Nothing covers how DevicePolicy is reset, or that a mapper leaving device access unrestricted gets that, so neither a stale policy nor a reset that wrongly restricted a job would be caught. Add tests that modify_slice resets the policy when the mapper omits it, that a policy from the mapper overrides the reset, and that an "auto" policy with no devices granted is passed through, which is how access is left unrestricted. Assisted-by: Claude:Opus-5
Problem: The user slice is left with no resource constraints at all when the sdexec-mapper lookup fails. The exception is caught and reported as an empty property set, which the caller takes to mean there is nothing to constrain, so no cpuset and no device containment are applied and the prolog exits successfully. Let the error propagate, as the other constraint steps already do. The prolog and housekeeping report it and exit non-zero, draining the node, rather than admitting sessions to an unconstrained slice. Resource constraints are disabled with exec.sdexec-constrain- resources, not by an unreachable mapper. Update the lookup failure test, which asserted the empty result. Assisted-by: Claude:Opus-5
mergify
Bot
force-pushed
the
deviceallow-stale
branch
from
September 23, 2026 19:55
f647fdc to
59c816b
Compare
Contributor
Merge Queue Status
This pull request spent 46 seconds in the queue, including 8 seconds running CI. Required conditions to merge
|
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.
This PR fixes a few bugs that would allow stale properties, i.e. access to resources that aren't allocated, in user slices.
This is built on top of #32