-
Notifications
You must be signed in to change notification settings - Fork 166
composefs/status: resolve rollback entry correctly #1888
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request provides a solid fix for correctly identifying the rollback deployment in composefs status. The previous implementation, which assumed any non-booted/non-staged deployment was the rollback entry, was flawed and could lead to incorrect behavior, especially in the presence of stale deployment data. The new approach of cross-referencing deployments with the actual bootloader configuration (both BLS and Grub entries) is much more robust and correctly handles the logic. The changes are well-contained and the logic is sound. I have one suggestion to refactor a loop to be more idiomatic and improve clarity.
Previous implementation had undefined behavior and was coincidentally correct under conditions where no rollback was performed, see bootc-dev#1887 Matches deployment entries in composefs deploy folder that are neither staged nor booted against entires defined in /boot to find out rollback entry. Fixes bootc-dev#1887 Signed-off-by: Chaser Huang <huangkangjing@gmail.com>
38de23d to
84c98aa
Compare
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com> Signed-off-by: Chaser Huang <huangkangjing@gmail.com>
|
@cgwalters @Johan-Liebert1 Can anyone take a look at this change? I feel this change makes sense even without reproduction of #1887 since current implemented behavior relies on undefined behaviors from the underlying library/syscall ( syscall |
Could you please highlight the UB that might occur? I might be getting this wrong since I'm unable to reproduce #1887, but wouldn't |
|
UB comes from these code that reads the entries from directory bootc/crates/lib/src/bootc_composefs/status.rs Lines 545 to 549 in ad60763
The read_dir function doc describes the order of the returned entry list to be UB.Later in the same function, this list with undefined order is enumerated through: bootc/crates/lib/src/bootc_composefs/status.rs Lines 573 to 621 in ad60763
Within this loop, host.status.booted and host.status.staged are both set and early continues the loop, and the last statement catches all fall-through cases and sets host.status.rollback.
But if there are more than two entires in If the UB here picked up an entry that does have a corresponding bootc/crates/lib/src/bootc_composefs/status.rs Lines 444 to 452 in ad60763
find_bls_entry would fail on host.status.rollback due to the missing BLS entry, causing #1887
As for here in my change, that section is trying to find boot entries that are neither the booted entry nor the staged entry, and are in both |
Johan-Liebert1
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this patch
Previous implementation had undefined behavior and was coincidentally correct under conditions where no rollback was performed, see #1887
Matches deployment entries in composefs deploy folder that are neither staged nor booted against entires defined in /boot to find out rollback entry.
Fixes #1887