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;
Message-ID: <953dda90-5a73-01f0-e5b7-2607e67dec13@suse.cz>
Date:   Wed, 11 Jan 2023 15:29:29 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Subject: Re: mm/kmsan/instrumentation.c:41:26: warning: no previous prototype
 for function '__msan_metadata_ptr_for_load_n'
Content-Language: en-US
To:     Alexander Potapenko <glider@google.com>
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>
References: <202301020356.dFruA4I5-lkp@intel.com>
 <aa722a69-8493-b449-c80c-a7cc1cf8a1b6@suse.cz>
 <CAG_fn=XmHKvpev4Gxv=SFOf2Kz0AwiuudXPqPjVJJo2gN=yOcg@mail.gmail.com>
From:   Vlastimil Babka <vbabka@suse.cz>
In-Reply-To: <CAG_fn=XmHKvpev4Gxv=SFOf2Kz0AwiuudXPqPjVJJo2gN=yOcg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 1/11/23 13:10, Alexander Potapenko wrote:
> On Mon, Jan 2, 2023 at 11:01 AM Vlastimil Babka <vbabka@suse.cz> wrote:
>>
>> +CC kmsan folks.
>>
>> I think it's another side-effect where CONFIG_SLUB_TINY excludes KASAN which
>> in turn allows KMSAN to be enabled and uncover a pre-existing issue.
> 
>  Thanks for bringing this up, I'll fix this as Marco proposes.
> 
> 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.