[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230116184127.GA1721129@roeck-us.net>
Date: Mon, 16 Jan 2023 10:41:27 -0800
From: Guenter Roeck <linux@...ck-us.net>
To: Heiko Carstens <hca@...ux.ibm.com>
Cc: Geert Uytterhoeven <geert@...ux-m68k.org>,
linux-kernel@...r.kernel.org, linux-s390@...r.kernel.org,
Alexander Gordeev <agordeev@...ux.ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>
Subject: Re: Build regressions/improvements in v6.2-rc4
On Mon, Jan 16, 2023 at 05:40:00PM +0100, Heiko Carstens wrote:
> On Mon, Jan 16, 2023 at 01:36:34PM +0100, Geert Uytterhoeven wrote:
> > On Mon, 16 Jan 2023, Geert Uytterhoeven wrote:
> > > JFYI, when comparing v6.2-rc4[1] to v6.2-rc3-8-g1fe4fd6f5cad346e[3], the summaries are:
> > > - build errors: +1/-5
> >
> > + /kisskb/src/include/linux/fortify-string.h: error: '__builtin_memcpy' reading 128 bytes from a region of size 0 [-Werror=stringop-overread]: => 57:33
> >
> > s390x-gcc11/s390-allmodconfig
> >
> > /kisskb/src/arch/s390/kernel/setup.c: In function 'setup_lowcore_dat_on':
> > /kisskb/src/include/linux/fortify-string.h:57:33: error: '__builtin_memcpy' reading 128 bytes from a region of size 0 [-Werror=stringop-overread]
> > 57 | #define __underlying_memcpy __builtin_memcpy
> > | ^
> > /kisskb/src/include/linux/fortify-string.h:578:9: note: in expansion of macro '__underlying_memcpy'
> > 578 | __underlying_##op(p, q, __fortify_size); \
> > | ^~~~~~~~~~~~~
> > /kisskb/src/include/linux/fortify-string.h:623:26: note: in expansion of macro '__fortify_memcpy_chk'
> > 623 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \
> > | ^~~~~~~~~~~~~~~~~~~~
> > /kisskb/src/arch/s390/kernel/setup.c:526:9: note: in expansion of macro 'memcpy'
> > 526 | memcpy(abs_lc->cregs_save_area, S390_lowcore.cregs_save_area,
> > | ^~~~~~
> >
> > Looks like this was "'__builtin_memcpy' offset [0, 127] is out of the bounds
> > [0, 0]" before.
>
> Thanks for reporting. Of course this doesn't happen with gcc-12, and
> this code will be rewritten with the next merge window anyway.
> But to workaround this with gcc-11, we could go with the below:
>
This is because of
#define S390_lowcore (*((struct lowcore *) 0))
and is fixed with something like
#define S390_lowcore (*((struct lowcore *) absolute_pointer(0)))
See commit f6b5f1a56987 ("compiler.h: Introduce absolute_pointer macro").
The problem is only seen with gcc 11.2. I don't see it with 11.3 or 12.2.
Guenter
> diff --git a/arch/s390/kernel/setup.c b/arch/s390/kernel/setup.c
> index 2b6091349daa..696c9e007a36 100644
> --- a/arch/s390/kernel/setup.c
> +++ b/arch/s390/kernel/setup.c
> @@ -508,6 +508,7 @@ static void __init setup_lowcore_dat_on(void)
> {
> struct lowcore *abs_lc;
> unsigned long flags;
> + int i;
>
> __ctl_clear_bit(0, 28);
> S390_lowcore.external_new_psw.mask |= PSW_MASK_DAT;
> @@ -523,8 +524,8 @@ static void __init setup_lowcore_dat_on(void)
> abs_lc = get_abs_lowcore(&flags);
> abs_lc->restart_flags = RESTART_FLAG_CTLREGS;
> abs_lc->program_new_psw = S390_lowcore.program_new_psw;
> - memcpy(abs_lc->cregs_save_area, S390_lowcore.cregs_save_area,
> - sizeof(abs_lc->cregs_save_area));
> + for (i = 0; i < 16; i++)
> + abs_lc->cregs_save_area[i] = S390_lowcore.cregs_save_area[i];
> put_abs_lowcore(abs_lc, flags);
> }
>
Powered by blists - more mailing lists