Page MenuHomeFreeBSD

tunefs: Better fix for arm64 alignment issues
ClosedPublic

Authored by des on Fri, Apr 3, 5:11 PM.
Tags
None
Referenced Files
F151348156: D56245.id174935.diff
Tue, Apr 7, 7:11 PM
F151347311: D56245.diff
Tue, Apr 7, 7:01 PM
Unknown Object (File)
Sun, Apr 5, 10:46 AM
Unknown Object (File)
Fri, Apr 3, 5:29 PM
Subscribers

Details

Summary

Rather than trust that the compiler will lay out the stack frame the
way we expect it to, use a union to force the correct alignment.

MFC after: 1 week
Fixes: 616f47f176c3 ("tunefs: Fix alignment warning on arm64")

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 71947
Build 68830: arc lint + arc unit

Event Timeline

des requested review of this revision.Fri, Apr 3, 5:11 PM

If __aligned(sizeof(max_aljgn_t)) or some variant works on stack buffers, that seems like a reasonable solution for these as well

sbin/tunefs/tunefs.c
643

Applies here as well, no?

731

And here

You could also do something similar with the directory filling routine dir_clear_block() and the two functions that call it dir_insert() and dir_extend().

sbin/tunefs/tunefs.c
643

Here we're adding a variable offset to the pointer before casting, we should assert that alignment is preserved but the union trick won't help us, and in fact a corrupt or manipulated file system can cause us to perform an unaligned read.

731

Here we add a caller-provided offset to the pointer before casting, we should assert that alignment is preserved but the union trick won't help us.

sbin/tunefs/tunefs.c
643

I mean, we know that it needs to be aligned at least enough for a struct direct given that it immediately uses offset 0 as such. That's why I suggested in the overall comment that __aligned would be useful if it works on stack vars to force over-alignment in these cases to just not worry about it.

des marked 3 inline comments as done.Sun, Apr 5, 3:05 PM

This now looks complete and correct.

This revision is now accepted and ready to land.Sun, Apr 5, 10:02 PM
This revision was automatically updated to reflect the committed changes.