linux-kernel - Re: mainline build failure due to e240e53ae0ab ("mm, slub: add CONFIG_SLUB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 13 Dec 2022 16:21:02 +0100
From:   Vlastimil Babka <vbabka@...e.cz>
To:     Guenter Roeck <linux@...ck-us.net>,
        "Sudip Mukherjee (Codethink)" <sudipm.mukherjee@...il.com>
Cc:     Andrey Ryabinin <ryabinin.a.a@...il.com>,
        Alexander Potapenko <glider@...gle.com>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        kasan-dev@...glegroups.com, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, Linus Torvalds <torvalds@...ux-foundation.org>,
        Marco Elver <elver@...gle.com>
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/14bd73b0-5480-2b35-7b89-161075d9f444@suse.cz/

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
>