Re: [PATCH] string: uninline memcpy_and_pad

[Guenter Roeck]

On 11/2/21 12:56 AM, Geert Uytterhoeven wrote:
> Hi Günter,
>
> Thanks for your patch!
>
> On Tue, Nov 2, 2021 at 5:30 AM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
> > 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@xxxxxxxxxxxxxxxxxxxx>
> > Cc: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
> > Signed-off-by: Guenter Roeck <linux@xxxxxxxxxxxx>
>
> Reviewed-by: Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>
>
> >   include/linux/string.h | 19 ++-----------------
> >   lib/string.c           | 19 +++++++++++++++++++
> >   2 files changed, 21 insertions(+), 17 deletions(-)
>
> Given this now conflicts with commit cfecea6ead5f1588 ("lib/string:
> Move helper functions out of string.c"). perhaps you should move this
> to lib/string_helpers.c when respinning?

Will do.

Thanks,
Guenter