schfs: records at arbitrary offsets are packed, and the compiler is told
A leaf's value area holds variable-length records end to end, so a record begins wherever the one before it finished -- a multiple of 8 only by luck. The code reads them by casting a pointer into the block, which tells the compiler they are aligned when they are not. That works on x86, which is why it has never shown as a bug, and it is undefined in C. A compiler entitled to assume 8-byte alignment may emit an instruction that requires it, and the failure would arrive at a different optimisation level or on a different architecture looking like filesystem corruption rather than like codegen. UndefinedBehaviorSanitizer reported 31 of them across obj.c, objw.c, attr.c and space.c. Seven types now carry SCHFS_PACKED: dirent_rec, extent, extref, index_rec, attr_rec, snap and inode. Two of those -- attr_rec and inode -- were never reported, because schfs_objtest does not reach an unaligned instance of either. They were latent rather than absent, and casting into a leaf is the same lie whether or not a test has caught it yet. NO ON-DISK LAYOUT CHANGED, and that was measured before the annotation was applied rather than assumed: every one of these already carries explicit `pad` fields and therefore has no implicit padding, so sizes and member offsets are identical with and without it. Seven _Static_asserts now pin the sizes, because a record that silently grows misreads every existing volume from that point on and looks like corruption rather than like a struct that changed. schfs_node_hdr, schfs_item, schfs_kptr and schfs_uberblock are deliberately left alone. The node header is exactly 32 bytes, so the items and key pointers after it are already 8-aligned, and annotating them would cost byte-wise access on the tree's hottest paths to fix a problem they do not have. Verified by reading an image written before the change: schfs_fsck --check passes on structure, checksums, key ordering, data blocks and derived free space, and the kernel mounts its own root unchanged. Also here: mkschfs passed a null pointer to qsort for an empty directory. Every implementation ignores it when the count is zero; the standard does not say they have to. make schfs-check now runs with no sanitizer output at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
This commit is contained in:
parent
25530e7eed
commit
7c8cf51941
5 changed files with 123 additions and 41 deletions
|
|
@ -584,7 +584,11 @@ add_tree(uint64_t dirino, const char *hostdir)
|
|||
}
|
||||
closedir(d);
|
||||
|
||||
qsort(l.v, l.n, sizeof(*l.v), nl_cmp);
|
||||
// qsort declares its first argument non-null, and an empty directory
|
||||
// leaves l.v at NULL. Every implementation ignores the pointer when the
|
||||
// count is zero; the standard does not say they have to.
|
||||
if (l.n > 0)
|
||||
qsort(l.v, l.n, sizeof(*l.v), nl_cmp);
|
||||
long subdirs = 0;
|
||||
for (int i = 0; i < l.n; i++) {
|
||||
subdirs += add_entry(dirino, hostdir, l.v[i]);
|
||||
|
|
|
|||
Loading…
Reference in a new issue