2023-01-16 13:10:30

by Geert Uytterhoeven

[permalink] [raw]
Subject: Re: Build regressions/improvements in v6.2-rc4

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.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


2023-01-16 17:57:13

by Heiko Carstens

[permalink] [raw]
Subject: Re: Build regressions/improvements in v6.2-rc4

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:

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);
}

2023-01-16 19:44:00

by Guenter Roeck

[permalink] [raw]
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);
> }
>

2023-01-17 09:16:42

by Heiko Carstens

[permalink] [raw]
Subject: Re: Build regressions/improvements in v6.2-rc4

On Mon, Jan 16, 2023 at 10:41:27AM -0800, Guenter Roeck wrote:
> 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").

Yes, I'm aware of that. However absolute_pointer() is not an option for
S390_lowcore. See also commit f0be87c42cbd ("gcc-12: disable
'-Warray-bounds' universally for now") and the referenced s390 commit.

> The problem is only seen with gcc 11.2. I don't see it with 11.3 or 12.2.

FWIW, the compile warning is seen with gcc 11.1 and 11.2, but not with any
other compiler. Given that this isn't the first report, I'm tempted to
workaround this now.

2023-01-17 09:17:31

by Guenter Roeck

[permalink] [raw]
Subject: Re: Build regressions/improvements in v6.2-rc4

On 1/17/23 00:57, Heiko Carstens wrote:
> On Mon, Jan 16, 2023 at 10:41:27AM -0800, Guenter Roeck wrote:
>> 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").
>
> Yes, I'm aware of that. However absolute_pointer() is not an option for
> S390_lowcore. See also commit f0be87c42cbd ("gcc-12: disable
> '-Warray-bounds' universally for now") and the referenced s390 commit.
>

Interesting. It works (builds) just fine for me after the above suggested
change.

Guenter

>> The problem is only seen with gcc 11.2. I don't see it with 11.3 or 12.2.
>
> FWIW, the compile warning is seen with gcc 11.1 and 11.2, but not with any
> other compiler. Given that this isn't the first report, I'm tempted to
> workaround this now.