summaryrefslogtreecommitdiffstats
path: root/fs
diff options
context:
space:
mode:
authorGuenter Roeck <linux@roeck-us.net>2021-11-02 15:24:20 +0100
committerLinus Torvalds <torvalds@linux-foundation.org>2021-11-03 19:41:25 +0100
commit5c4e0a21fae877a7ef89be6dcc6263ec672372b8 (patch)
treea0b78cdf3be8bcbfa5a78209370c07df19128104 /fs
parentMerge tag 'jfs-5.16' of git://github.com/kleikamp/linux-shaggy (diff)
downloadlinux-5c4e0a21fae877a7ef89be6dcc6263ec672372b8.tar.xz
linux-5c4e0a21fae877a7ef89be6dcc6263ec672372b8.zip
string: uninline memcpy_and_pad
When building m68k:allmodconfig, recent versions of gcc generate the following error if the length of UTS_RELEASE is less than 8 bytes. In function 'memcpy_and_pad', inlined from 'nvmet_execute_disc_identify' at drivers/nvme/target/discovery.c:268:2: arch/m68k/include/asm/string.h:72:25: error: '__builtin_memcpy' reading 8 bytes from a region of size 7 Discussions around the problem suggest that this only happens if an architecture does not provide strlen(), if -ffreestanding is provided as compiler option, and if CONFIG_FORTIFY_SOURCE=n. All of this is the case for m68k. The exact reasons are unknown, but seem to be related to the ability of the compiler to evaluate the return value of strlen() and the resulting execution flow in memcpy_and_pad(). It would be possible to work around the problem by using sizeof(UTS_RELEASE) instead of strlen(UTS_RELEASE), but that would only postpone the problem until the function is called in a similar way. Uninline memcpy_and_pad() instead to solve the problem for good. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs')
0 files changed, 0 insertions, 0 deletions