dm vdo user: Build with -fno-strict-aliasing [VDO-5943] #385
Conversation
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
We borrow code from the kernel tree for our user-mode builds to support using the same (kernel) APIs everywhere. However, the kernel builds using -fno-strict-aliasing, even in its tools/ subdirectory, and that affects how optimization may alter the code's behavior, as some kernel code may not perform correctly without it. We don't currently use that option when building programs in user mode. We've observed that the READ_ONCE and WRITE_ONCE macros borrowed from $kernel/tools/ (the version defined for internal testing only) are not safe when applied to pointer objects in some cases due to aliasing issues. So far we've noticed no issues that would affect end users, but this isn't the only code we've borrowed from the kernel. It's better to be safe and disable such optimizations like the kernel does.
Member
Author
|
This is an alternative to the approach in PR #342 |
github-actions
bot
added
untested
private build running
public build running
and removed
untested
labels
lorelei-sakai
requested changes
Nov 21, 2025
Member
lorelei-sakai
left a comment
lorelei-sakai
left a comment
There was a problem hiding this comment.
Generally seems reasonable, but this change affects more than just the user build. Is that significant enough to call out?
github-actions
bot
added
private testing done
public testing done
and removed
private testing running
public testing running
labels
lorelei-sakai
approved these changes
Nov 21, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
We borrow code from the kernel tree for our user-mode builds to support using the same (kernel) APIs everywhere. However, the kernel builds using -fno-strict-aliasing, even in its tools/ subdirectory, and that affects how optimization may alter the code's behavior, as some kernel code may not perform correctly without it. We don't currently use that option when building programs in user mode.
We've observed that the READ_ONCE and WRITE_ONCE macros borrowed from $kernel/tools/ (the version defined for internal testing only) are not safe when applied to pointer objects in some cases due to aliasing issues. So far we've noticed no issues that would affect end users, but this isn't the only code we've borrowed from the kernel. It's better to be safe and disable such optimizations like the kernel does.