diff options
author | Guenter Roeck <linux@roeck-us.net> | 2021-11-02 07:24:20 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2021-11-03 11:41:25 -0700 |
commit | 5c4e0a21fae877a7ef89be6dcc6263ec672372b8 (patch) | |
tree | a0b78cdf3be8bcbfa5a78209370c07df19128104 /include/linux/sched | |
parent | 655fedaad36c0b31a6f6cb8f469b739b2359d74f (diff) | |
download | linux-stable-5c4e0a21fae877a7ef89be6dcc6263ec672372b8.tar.gz linux-stable-5c4e0a21fae877a7ef89be6dcc6263ec672372b8.tar.bz2 linux-stable-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 'include/linux/sched')
0 files changed, 0 insertions, 0 deletions