[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+fCnZdZQFVBf_NkrKk0U+TAptfi6RRmCkPY5ZpOUeObBpwAnQ@mail.gmail.com>
Date: Fri, 5 Dec 2025 16:07:10 +0100
From: Andrey Konovalov <andreyknvl@...il.com>
To: Baoquan He <bhe@...hat.com>
Cc: linux-mm@...ck.org, ryabinin.a.a@...il.com, glider@...gle.com,
dvyukov@...gle.com, vincenzo.frascino@....com, akpm@...ux-foundation.org,
kasan-dev@...glegroups.com, linux-kernel@...r.kernel.org,
kexec@...ts.infradead.org, elver@...gle.com, sj@...nel.org,
lorenzo.stoakes@...cle.com, snovitoll@...il.com, christophe.leroy@...roup.eu
Subject: Re: [PATCH v4 01/12] mm/kasan: add conditional checks in functions to
return directly if kasan is disabled
On Fri, Dec 5, 2025 at 8:21 AM Baoquan He <bhe@...hat.com> wrote:
>
> On 12/04/25 at 05:38pm, Andrey Konovalov wrote:
> > On Fri, Nov 28, 2025 at 4:33 AM Baoquan He <bhe@...hat.com> wrote:
> > >
> > > The current codes only check if kasan is disabled for hw_tags
> > > mode. Here add the conditional checks for functional functions of
> > > generic mode and sw_tags mode.
> > >
> > > This is prepared for later adding kernel parameter kasan=on|off for
> > > all three kasan modes.
> > >
> > > Signed-off-by: Baoquan He <bhe@...hat.com>
> > > ---
> > > mm/kasan/generic.c | 17 +++++++++++++++--
> > > mm/kasan/init.c | 6 ++++++
> > > mm/kasan/quarantine.c | 3 +++
> > > mm/kasan/report.c | 4 +++-
> > > mm/kasan/shadow.c | 11 ++++++++++-
> > > mm/kasan/sw_tags.c | 3 +++
> > > 6 files changed, 40 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > > index 2b8e73f5f6a7..aff822aa2bd6 100644
> > > --- a/mm/kasan/generic.c
> > > +++ b/mm/kasan/generic.c
> > > @@ -214,12 +214,13 @@ bool kasan_byte_accessible(const void *addr)
> > >
> > > void kasan_cache_shrink(struct kmem_cache *cache)
> > > {
> > > - kasan_quarantine_remove_cache(cache);
> > > + if (kasan_enabled())
> >
> > Please move these checks to include/linux/kasan.h and add __helpers to
> > consistent with how it's done for other KASAN annotation calls.
> > Otherwise eventually these checks start creeping into lower level
> > functions and the logic of checking when and whether KASAN is enabled
> > becomes a mess.
>
> Not sure if I got it correctly. Are you suggesting it should be done
> like kasan_populate_vmalloc()/__kasan_populate_vmalloc(),
> kasan_release_vmalloc()/__kasan_release_vmalloc()?
Yes, please (assuming you're referring to how these functions are
defined with all Sabyrzhan's patches applied).
Powered by blists - more mailing lists