# git rev-parse -q --verify b7213ffa0e585feb1aee3e7173e965e66ee0abaa^{commit}
b7213ffa0e585feb1aee3e7173e965e66ee0abaa
already have revision, skipping fetch
# git checkout -q -f -B kisskb b7213ffa0e585feb1aee3e7173e965e66ee0abaa
# git clean -qxdf
# < git log -1
# commit b7213ffa0e585feb1aee3e7173e965e66ee0abaa
# Author: Linus Torvalds <torvalds@linux-foundation.org>
# Date:   Wed Sep 15 13:56:37 2021 -0700
# 
#     qnx4: avoid stringop-overread errors
#     
#     The qnx4 directory entries are 64-byte blocks that have different
#     contents depending on the a status byte that is in the last byte of the
#     block.
#     
#     In particular, a directory entry can be either a "link info" entry with
#     a 48-byte name and pointers to the real inode information, or an "inode
#     entry" with a smaller 16-byte name and the full inode information.
#     
#     But the code was written to always just treat the directory name as if
#     it was part of that "inode entry", and just extend the name to the
#     longer case if the status byte said it was a link entry.
#     
#     That work just fine and gives the right results, but now that gcc is
#     tracking data structure accesses much more, the code can trigger a
#     compiler error about using up to 48 bytes (the long name) in a structure
#     that only has that shorter name in it:
#     
#        fs/qnx4/dir.c: In function ‘qnx4_readdir’:
#        fs/qnx4/dir.c:51:32: error: ‘strnlen’ specified bound 48 exceeds source size 16 [-Werror=stringop-overread]
#           51 |                         size = strnlen(de->di_fname, size);
#              |                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~
#        In file included from fs/qnx4/qnx4.h:3,
#                         from fs/qnx4/dir.c:16:
#        include/uapi/linux/qnx4_fs.h:45:25: note: source object declared here
#           45 |         char            di_fname[QNX4_SHORT_NAME_MAX];
#              |                         ^~~~~~~~
#     
#     which is because the source code doesn't really make this whole "one of
#     two different types" explicit.
#     
#     Fix this by introducing a very explicit union of the two types, and
#     basically explaining to the compiler what is really going on.
#     
#     Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
# < /opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux-gcc --version
# < /opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux-ld --version
# < git log --format=%s --max-count=1 b7213ffa0e585feb1aee3e7173e965e66ee0abaa
# < make -s -j 8 ARCH=x86 O=/kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux-  x86_64_defconfig
# < make -s -j 8 ARCH=x86 O=/kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux-  help
# make -s -j 8 ARCH=x86 O=/kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux-  olddefconfig
# make -s -j 8 ARCH=x86 O=/kisskb/build/linus_x86_64_defconfig_x86_64-gcc8 CROSS_COMPILE=/opt/cross/kisskb/korg/gcc-8.1.0-nolibc/x86_64-linux/bin/x86_64-linux-  
Completed OK
# rm -rf /kisskb/build/linus_x86_64_defconfig_x86_64-gcc8
# Build took: 0:04:08.194359