I was playing around with the new-ish "-fsanitize=undefined" compiler
flag, and it detected a few problems:
1. We sometimes bit-shift signed constants too far (fixed by the first
patch).
2. We have some unaligned memory accesses that presumably work OK on
x86, but would blow up on ARM or other platforms (I didn't test).
The latter looks like it's in the untracked cache code (Duy and
Christian cc'd). Running t7063 gets me this:
dir.c:2631:45: runtime error: member access within misaligned address 0x7f19806ff185 for type 'const struct ondisk_untracked_cache', which requires 4 byte alignment
0x7f19806ff185: note: pointer points here
31 33 29 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^
We also do unaligned loads in the get_be* functions, but only on x86 and
similar platforms. I'm counting these as a false positive, since it is
presumably OK there. The second patch makes it easier to squelch these.
I also got false positives from feeding NULL to qsort(). This is
technically wrong, but OK in practice when we tell it we have zero
elements. Compiling with INTERNAL_QSORT silences these (and if somebody
is on a platform where their qsort() segfaults, it's what I'd tell them
to use).
So if you want to play along at home, my build is something like:
make \
CC=clang \
INTERNAL_QSORT=YesPlease \
CFLAGS='-O2 -g -fsanitize=undefined -fno-sanitize-recover=undefined -DNO_UNALIGNED_LOADS' \
test
and it passes except for t7063.
The patches are:
[1/2]: avoid shifting signed integers 31 bits
[2/2]: bswap: add NO_UNALIGNED_LOADS define
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html