[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAG_fn=UvnHd_gVuqkWEC9RLBUjreD-BC8sb67nLD=bq+SP7Zfw@mail.gmail.com>
Date: Thu, 12 Jan 2023 11:26:04 +0100
From: Alexander Potapenko <glider@...gle.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: kernel test robot <lkp@...el.com>, llvm@...ts.linux.dev,
oe-kbuild-all@...ts.linux.dev, linux-kernel@...r.kernel.org,
Christoph Lameter <cl@...ux-foundation.org>,
Marco Elver <elver@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
kasan-dev <kasan-dev@...glegroups.com>
Subject: Re: mm/kmsan/instrumentation.c:41:26: warning: no previous prototype
for function '__msan_metadata_ptr_for_load_n'
On Thu, Jan 12, 2023 at 10:15 AM Alexander Potapenko <glider@...gle.com> wrote:
>
> > > 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 only
> > 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:
False alarm, a reduced config works fine with both KMSAN and
SLUB_TINY. Perhaps the one I was trying previously was too heavy.
Powered by blists - more mailing lists