2022-12-13 11:20:47

by Sudip Mukherjee

[permalink] [raw]
Subject: mainline build failure due to e240e53ae0ab ("mm, slub: add CONFIG_SLUB_TINY")

Hi All,

The latest mainline kernel branch fails to build xtensa allmodconfig
with gcc-11 with the error:

kernel/kcsan/kcsan_test.c: In function '__report_matches':
kernel/kcsan/kcsan_test.c:257:1: error: the frame size of 1680 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
257 | }
| ^

git bisect pointed to e240e53ae0ab ("mm, slub: add CONFIG_SLUB_TINY")


I will be happy to test any patch or provide any extra log if needed.

Note:
This is only seen with gcc-11, gcc-12 builds are ok.

--
Regards
Sudip


2022-12-13 11:41:30

by Sudip Mukherjee

[permalink] [raw]
Subject: Re: mainline build failure due to e240e53ae0ab ("mm, slub: add CONFIG_SLUB_TINY")

On Tue, 13 Dec 2022 at 10:26, Sudip Mukherjee (Codethink)
<[email protected]> wrote:
>
> Hi All,
>
> The latest mainline kernel branch fails to build xtensa allmodconfig
> with gcc-11 with the error:

And, also powerpc allmodconfig with the error:

fs/f2fs/inline.c: In function 'f2fs_move_inline_dirents':
./include/linux/fortify-string.h:59:33: error: '__builtin_memset'
pointer overflow between offset [28, 898293814] and size [-898293787,
-1] [-Werror=array-bounds]
59 | #define __underlying_memset __builtin_memset
| ^
./include/linux/fortify-string.h:337:9: note: in expansion of macro
'__underlying_memset'
337 | __underlying_memset(p, c, __fortify_size);
\
| ^~~~~~~~~~~~~~~~~~~
./include/linux/fortify-string.h:345:25: note: in expansion of macro
'__fortify_memset_chk'
345 | #define memset(p, c, s) __fortify_memset_chk(p, c, s,
\
| ^~~~~~~~~~~~~~~~~~~~
fs/f2fs/inline.c:430:9: note: in expansion of macro 'memset'
430 | memset(dst.bitmap + src.nr_bitmap, 0, dst.nr_bitmap -
src.nr_bitmap);
| ^~~~~~

Note: the powerpc failure is also with gcc-11 only. gcc-12 builds fine.


--
Regards
Sudip

2022-12-13 13:06:57

by Guenter Roeck

[permalink] [raw]
Subject: Re: mainline build failure due to e240e53ae0ab ("mm, slub: add CONFIG_SLUB_TINY")

On Tue, Dec 13, 2022 at 10:39:30AM +0000, Sudip Mukherjee wrote:
> On Tue, 13 Dec 2022 at 10:26, Sudip Mukherjee (Codethink)
> <[email protected]> wrote:
> >
> > Hi All,
> >
> > The latest mainline kernel branch fails to build xtensa allmodconfig
> > with gcc-11 with the error:
>
> And, also powerpc allmodconfig with the error:
>

Plus arm:allmodconfig, with gcc 11.3.

In file included from include/linux/string.h:253,
from include/linux/bitmap.h:11,
from include/linux/cpumask.h:12,
from include/linux/mm_types_task.h:14,
from include/linux/mm_types.h:5,
from include/linux/buildid.h:5,
from include/linux/module.h:14,
from drivers/crypto/caam/compat.h:10,
from drivers/crypto/caam/key_gen.c:8:
drivers/crypto/caam/desc_constr.h: In function 'append_data.constprop':
include/linux/fortify-string.h:57:33: error: argument 2 null where non-null expected [-Werror=nonnull]
57 | #define __underlying_memcpy __builtin_memcpy
| ^
include/linux/fortify-string.h:469:9: note: in expansion of macro '__underlying_memcpy'
469 | __underlying_##op(p, q, __fortify_size); \
| ^~~~~~~~~~~~~
include/linux/fortify-string.h:514:26: note: in expansion of macro '__fortify_memcpy_chk'
514 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \
| ^~~~~~~~~~~~~~~~~~~~
drivers/crypto/caam/desc_constr.h:167:17: note: in expansion of macro 'memcpy'
167 | memcpy(offset, data, len);
| ^~~~~~
include/linux/fortify-string.h:57:33: note: in a call to built-in function '__builtin_memcpy'
57 | #define __underlying_memcpy __builtin_memcpy
| ^
include/linux/fortify-string.h:469:9: note: in expansion of macro '__underlying_memcpy'
469 | __underlying_##op(p, q, __fortify_size); \
| ^~~~~~~~~~~~~
include/linux/fortify-string.h:514:26: note: in expansion of macro '__fortify_memcpy_chk'
514 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \
| ^~~~~~~~~~~~~~~~~~~~
drivers/crypto/caam/desc_constr.h:167:17: note: in expansion of macro 'memcpy'
167 | memcpy(offset, data, len);

Guenter

2022-12-13 13:21:27

by Guenter Roeck

[permalink] [raw]
Subject: Re: mainline build failure due to e240e53ae0ab ("mm, slub: add CONFIG_SLUB_TINY")

On Tue, Dec 13, 2022 at 10:26:20AM +0000, Sudip Mukherjee (Codethink) wrote:
> Hi All,
>
> The latest mainline kernel branch fails to build xtensa allmodconfig
> with gcc-11 with the error:
>
> kernel/kcsan/kcsan_test.c: In function '__report_matches':
> kernel/kcsan/kcsan_test.c:257:1: error: the frame size of 1680 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
> 257 | }
> | ^
>
> git bisect pointed to e240e53ae0ab ("mm, slub: add CONFIG_SLUB_TINY")
>

In part that is because above commit changes Kconfig dependencies such
that xtensa:allmodconfig actually tries to build kernel/kcsan/kcsan_test.o.
In v6.1, CONFIG_KCSAN_KUNIT_TEST is not enabled for xtensa:allmodconfig.

Downside of the way SLUB_TINY is defined is that it is enabled for all
allmodconfig / allyesconfig builds, which then disables building a lot
of the more sophisticated memory allocation options.

Guenter

2022-12-13 14:08:49

by Vlastimil Babka

[permalink] [raw]
Subject: Re: mainline build failure due to e240e53ae0ab ("mm, slub: add CONFIG_SLUB_TINY")

On 12/13/22 14:11, Guenter Roeck wrote:
> On Tue, Dec 13, 2022 at 10:26:20AM +0000, Sudip Mukherjee (Codethink) wrote:
>> Hi All,
>>
>> The latest mainline kernel branch fails to build xtensa allmodconfig
>> with gcc-11 with the error:
>>
>> kernel/kcsan/kcsan_test.c: In function '__report_matches':
>> kernel/kcsan/kcsan_test.c:257:1: error: the frame size of 1680 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
>> 257 | }
>> | ^
>>
>> git bisect pointed to e240e53ae0ab ("mm, slub: add CONFIG_SLUB_TINY")
>>
>
> In part that is because above commit changes Kconfig dependencies such
> that xtensa:allmodconfig actually tries to build kernel/kcsan/kcsan_test.o.
> In v6.1, CONFIG_KCSAN_KUNIT_TEST is not enabled for xtensa:allmodconfig.

OK, so IIUC
- e240e53ae0ab introduces SLUB_TINY and adds !SLUB_TINY to KASAN's depend
- allyesconfig/allmodconfig will enable SLUB_TINY
- thus KASAN is disabled where it was previously enabled
- thus KCSAN which depends on !KASAN is enabled where it was previously disabled
- also arch/xtensa/Kconfig: select ARCH_HAS_STRNCPY_FROM_USER if !KASAN

> Downside of the way SLUB_TINY is defined is that it is enabled for all
> allmodconfig / allyesconfig builds, which then disables building a lot
> of the more sophisticated memory allocation options.

It does disable KASAN, but seems that on the other hand allows enabling
other stuff.
Is there a way to exclude the SLUB_TINY option from all(mod/yes)config? Or
it needs to be removed to SLUB_FULL and logically reversed?

> Guenter

2022-12-13 15:38:21

by Guenter Roeck

[permalink] [raw]
Subject: Re: mainline build failure due to e240e53ae0ab ("mm, slub: add CONFIG_SLUB_TINY")

On 12/13/22 05:27, Vlastimil Babka wrote:
> On 12/13/22 14:11, Guenter Roeck wrote:
>> On Tue, Dec 13, 2022 at 10:26:20AM +0000, Sudip Mukherjee (Codethink) wrote:
>>> Hi All,
>>>
>>> The latest mainline kernel branch fails to build xtensa allmodconfig
>>> with gcc-11 with the error:
>>>
>>> kernel/kcsan/kcsan_test.c: In function '__report_matches':
>>> kernel/kcsan/kcsan_test.c:257:1: error: the frame size of 1680 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
>>> 257 | }
>>> | ^
>>>
>>> git bisect pointed to e240e53ae0ab ("mm, slub: add CONFIG_SLUB_TINY")
>>>
>>
>> In part that is because above commit changes Kconfig dependencies such
>> that xtensa:allmodconfig actually tries to build kernel/kcsan/kcsan_test.o.
>> In v6.1, CONFIG_KCSAN_KUNIT_TEST is not enabled for xtensa:allmodconfig.
>
> OK, so IIUC
> - e240e53ae0ab introduces SLUB_TINY and adds !SLUB_TINY to KASAN's depend
> - allyesconfig/allmodconfig will enable SLUB_TINY
> - thus KASAN is disabled where it was previously enabled
> - thus KCSAN which depends on !KASAN is enabled where it was previously disabled
> - also arch/xtensa/Kconfig: select ARCH_HAS_STRNCPY_FROM_USER if !KASAN
>
>> Downside of the way SLUB_TINY is defined is that it is enabled for all
>> allmodconfig / allyesconfig builds, which then disables building a lot
>> of the more sophisticated memory allocation options.
>
> It does disable KASAN, but seems that on the other hand allows enabling
> other stuff.
> Is there a way to exclude the SLUB_TINY option from all(mod/yes)config? Or
> it needs to be removed to SLUB_FULL and logically reversed?
>

"depends on !COMPILE_TEST" should do it. Not sure though if that would just
hide the other compile failures seen with powerpc and arm allmodconfig
builds.

Guenter

2022-12-13 15:41:06

by Vlastimil Babka

[permalink] [raw]
Subject: Re: mainline build failure due to e240e53ae0ab ("mm, slub: add CONFIG_SLUB_TINY")

On 12/13/22 15:11, Guenter Roeck wrote:
> On 12/13/22 05:27, Vlastimil Babka wrote:
>> On 12/13/22 14:11, Guenter Roeck wrote:
>>> On Tue, Dec 13, 2022 at 10:26:20AM +0000, Sudip Mukherjee (Codethink) wrote:
>>>> Hi All,
>>>>
>>>> The latest mainline kernel branch fails to build xtensa allmodconfig
>>>> with gcc-11 with the error:
>>>>
>>>> kernel/kcsan/kcsan_test.c: In function '__report_matches':
>>>> kernel/kcsan/kcsan_test.c:257:1: error: the frame size of 1680 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
>>>> 257 | }
>>>> | ^
>>>>
>>>> git bisect pointed to e240e53ae0ab ("mm, slub: add CONFIG_SLUB_TINY")
>>>>
>>>
>>> In part that is because above commit changes Kconfig dependencies such
>>> that xtensa:allmodconfig actually tries to build kernel/kcsan/kcsan_test.o.
>>> In v6.1, CONFIG_KCSAN_KUNIT_TEST is not enabled for xtensa:allmodconfig.
>>
>> OK, so IIUC
>> - e240e53ae0ab introduces SLUB_TINY and adds !SLUB_TINY to KASAN's depend
>> - allyesconfig/allmodconfig will enable SLUB_TINY
>> - thus KASAN is disabled where it was previously enabled
>> - thus KCSAN which depends on !KASAN is enabled where it was previously disabled
>> - also arch/xtensa/Kconfig: select ARCH_HAS_STRNCPY_FROM_USER if !KASAN
>>
>>> Downside of the way SLUB_TINY is defined is that it is enabled for all
>>> allmodconfig / allyesconfig builds, which then disables building a lot
>>> of the more sophisticated memory allocation options.
>>
>> It does disable KASAN, but seems that on the other hand allows enabling
>> other stuff.
>> Is there a way to exclude the SLUB_TINY option from all(mod/yes)config? Or
>> it needs to be removed to SLUB_FULL and logically reversed?
>>
>
> "depends on !COMPILE_TEST" should do it. Not sure though if that would just
> hide the other compile failures seen with powerpc and arm allmodconfig
> builds.

Hmm yeah it seems rather arbitrary and not fixing the root cause(s). If some
options are broken and it becomes apparent due to a change affecting
allmodconfig in a way that enables them, then I'd assume the same could have
already happened with randconfig? So it's best to fix that, or at least
disable those failing options on the respective arches deterministically.

Also worth noting why I resorted to making KASAN depend on !SLUB_TINY:

https://lore.kernel.org/all/[email protected]/

It's because KASAN_GENERIC and KASAN_SW_TAGS will "select SLUB_DEBUG if
SLUB" and apparently Kconfig doesn't consider it an error, but just a
warning, if that conficts with SLUB_DEBUG depending on !SLUB_TINY.
I just realized that KASAN_HW_TAGS doesn't have this 'select' so it could be
compatible with SLUB_TINY but I disabled that combination as well.

I suppose something like "select SLUB_TINY=n" doesn't exist, as that would
make the KASAN choice "stronger" than SLUB_TINY.

It would probably be the cleanest if the KASAN modes that need SLUB_DEBUG
just depended on it instead of selecting it.

> Guenter
>

2022-12-22 13:20:50

by Thorsten Leemhuis

[permalink] [raw]
Subject: Re: mainline build failure due to e240e53ae0ab ("mm, slub: add CONFIG_SLUB_TINY") #forregzbot

[Note: this mail contains only information for Linux kernel regression
tracking. Mails like these contain '#forregzbot' in the subject to make
then easy to spot and filter out. The author also tried to remove most
or all individuals from the list of recipients to spare them the hassle.]

On 13.12.22 11:26, Sudip Mukherjee (Codethink) wrote:
> Hi All,
>
> The latest mainline kernel branch fails to build xtensa allmodconfig
> with gcc-11 with the error:
>
> kernel/kcsan/kcsan_test.c: In function '__report_matches':
> kernel/kcsan/kcsan_test.c:257:1: error: the frame size of 1680 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
> 257 | }
> | ^
>
> git bisect pointed to e240e53ae0ab ("mm, slub: add CONFIG_SLUB_TINY")

Thanks for the report. To be sure below issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression
tracking bot:

#regzbot ^introduced e240e53ae0ab
#regzbot title mm, slub: CONFIG_SLUB_TINY causes various build errors
#regzbot ignore-activity

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.

2023-01-04 14:14:15

by Thorsten Leemhuis

[permalink] [raw]
Subject: Re: mainline build failure due to e240e53ae0ab ("mm, slub: add CONFIG_SLUB_TINY") #forregzbot

[TLDR: This mail in primarily relevant for Linux kernel regression
tracking. See link in footer if these mails annoy you.]

On 22.12.22 13:06, Thorsten Leemhuis wrote:
> [Note: this mail contains only information for Linux kernel regression
> tracking. Mails like these contain '#forregzbot' in the subject to make
> then easy to spot and filter out. The author also tried to remove most
> or all individuals from the list of recipients to spare them the hassle.]
>
> On 13.12.22 11:26, Sudip Mukherjee (Codethink) wrote:
>> Hi All,
>>
>> The latest mainline kernel branch fails to build xtensa allmodconfig
>> with gcc-11 with the error:
>>
>> kernel/kcsan/kcsan_test.c: In function '__report_matches':
>> kernel/kcsan/kcsan_test.c:257:1: error: the frame size of 1680 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
>> 257 | }
>> | ^
>>
>> git bisect pointed to e240e53ae0ab ("mm, slub: add CONFIG_SLUB_TINY")
>
> Thanks for the report. To be sure below issue doesn't fall through the
> cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression
> tracking bot:
>
> #regzbot ^introduced e240e53ae0ab
> #regzbot title mm, slub: CONFIG_SLUB_TINY causes various build errors
> #regzbot ignore-activity

#regzbot fix: kcsan: test: don't put the expect array on the stack

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.