Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <202301020356.dFruA4I5-lkp@intel.com> <aa722a69-8493-b449-c80c-a7cc1cf8a1b6@suse.cz>
 <CAG_fn=XmHKvpev4Gxv=SFOf2Kz0AwiuudXPqPjVJJo2gN=yOcg@mail.gmail.com> <953dda90-5a73-01f0-e5b7-2607e67dec13@suse.cz>
In-Reply-To: <953dda90-5a73-01f0-e5b7-2607e67dec13@suse.cz>
From:   Alexander Potapenko <glider@google.com>
Date:   Thu, 12 Jan 2023 10:15:45 +0100
Message-ID: <CAG_fn=Vz47zvCDoUENX5kH7Giena+w=yifWbMo28ayAUKU7kyQ@mail.gmail.com>
Subject: Re: mm/kmsan/instrumentation.c:41:26: warning: no previous prototype
 for function '__msan_metadata_ptr_for_load_n'
To:     Vlastimil Babka <vbabka@suse.cz>
Cc:     kernel test robot <lkp@intel.com>, llvm@lists.linux.dev,
        oe-kbuild-all@lists.linux.dev, linux-kernel@vger.kernel.org,
        Christoph Lameter <cl@linux-foundation.org>,
        Marco Elver <elver@google.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        kasan-dev <kasan-dev@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

> > Would it also make sense to exclude KMSAN with CONFIG_SLUB_TINY?
>
> If the root causes are fixed, then it's not necessary? AFAIK SLUB_TINY on=
ly
> indirectly caused KMSAN to be newly enabled in some configs, but there's =
no
> fundamental incompatibility that I know of.

So far I couldn't manage to boot KMSAN with SLUB_TINY, it just dies
somewhere very early with the following stacktrace:

#0  0xffffffff9044134a in native_halt () at ./arch/x86/include/asm/irqflags=
.h:57
#1  halt () at ./arch/x86/include/asm/irqflags.h:98
#2  early_fixup_exception (regs=3Dregs@entry=3D0xffffffff8fa03d08,
trapnr=3Dtrapnr@entry=3D14) at arch/x86/mm/extable.c:340
#3  0xffffffff903c23db in do_early_exception (regs=3D0xffffffff8fa03d08,
trapnr=3D14) at arch/x86/kernel/head64.c:424
#4  0xffffffff903c214f in early_idt_handler_common () at
arch/x86/kernel/head_64.S:483
#5  0x0000000000000000 in ?? ()

The same kernel boots (to some extent) without CONFIG_KMSAN, so my
guess is that we're instrumenting something that is not supposed to be
instrumented.
But SLUB_TINY doesn't add new source files, and it's also unlikely to
kick in before mm_init(), right?

--=20
Alexander Potapenko
Software Engineer

Google Germany GmbH
Erika-Mann-Stra=C3=9Fe, 33
80636 M=C3=BCnchen

Gesch=C3=A4ftsf=C3=BChrer: Paul Manicle, Liana Sebastian
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg