[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+a5q1dWrm+PhWH3uQRfLWZ0HOyHA6Er4V3bn9tk85TKYA@mail.gmail.com>
Date: Tue, 28 Jan 2020 07:25:59 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Qian Cai <cai@....pw>
Cc: Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Randy Dunlap <rdunlap@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Mark Brown <broonie@...nel.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux-MM <linux-mm@...ck.org>,
Linux-Next Mailing List <linux-next@...r.kernel.org>,
Michal Hocko <mhocko@...e.cz>, mm-commits@...r.kernel.org,
Stephen Rothwell <sfr@...b.auug.org.au>,
Ard Biesheuvel <ardb@...nel.org>,
linux-efi <linux-efi@...r.kernel.org>,
kasan-dev <kasan-dev@...glegroups.com>
Subject: Re: mmotm 2020-01-23-21-12 uploaded (efi)
On Tue, Jan 28, 2020 at 7:15 AM Qian Cai <cai@....pw> wrote:
> > Should be fixed by
> >
> > https://lore.kernel.org/linux-efi/20200121093912.5246-1-ardb@kernel.org/
>
> Cc kasan-devel@
>
> If everyone has to disable KASAN for the whole subdirectories like this, I am worried about we are losing testing coverage fairly quickly. Is there a bug in compiler?
My understanding is that this is invalid C code in the first place,
no? It just happened to compile with some compilers, some options and
probably only with high optimization level.
There is a known, simple fix that is used throughout the kernel -
provide empty static inline stub, or put whole calls under ifdef.
Powered by blists - more mailing lists