[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+fCnZce3AR+pUesbDkKMtMJ+iR8eDrcjFTbVpAcwjBoZ=gJnQ@mail.gmail.com>
Date: Tue, 23 Sep 2025 19:49:03 +0200
From: Andrey Konovalov <andreyknvl@...il.com>
To: Sabyrzhan Tasbolatov <snovitoll@...il.com>
Cc: ryabinin.a.a@...il.com, christophe.leroy@...roup.eu, bhe@...hat.com,
hca@...ux.ibm.com, akpm@...ux-foundation.org, zhangqing@...ngson.cn,
chenhuacai@...ngson.cn, davidgow@...gle.com, glider@...gle.com,
dvyukov@...gle.com, alexghiti@...osinc.com, alex@...ti.fr,
agordeev@...ux.ibm.com, vincenzo.frascino@....com, elver@...gle.com,
kasan-dev@...glegroups.com, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, loongarch@...ts.linux.dev,
linuxppc-dev@...ts.ozlabs.org, linux-riscv@...ts.infradead.org,
linux-s390@...r.kernel.org, linux-um@...ts.infradead.org, linux-mm@...ck.org
Subject: Re: [PATCH v6 1/2] kasan: introduce ARCH_DEFER_KASAN and unify static
key across modes
On Mon, Sep 15, 2025 at 6:30 AM Sabyrzhan Tasbolatov
<snovitoll@...il.com> wrote:
>
> > Why is the check removed here and in some other places below? This
> > need to be explained in the commit message.
>
> kasan_arch_is_ready which was unified with kasan_enabled, was removed
> here because
> __kasan_slab_pre_free is called from include/linux/kasan.h [1] where
> there's already kasan_enabled() check.
>
> [1] https://elixir.bootlin.com/linux/v6.16.7/source/include/linux/kasan.h#L198
>
> Please let me know if v7 is required with the change in the git commit
> message only.
No need, but next time please add such info into the commit message.
> > What I meant with these __wrappers was that we should add them for the
> > KASAN hooks that are called from non-KASAN code (i.e. for the hooks
> > defined in include/linux/kasan.h). And then move all the
> > kasan_enabled() checks from mm/kasan/* to where the wrappers are
> > defined in include/linux/kasan.h (see kasan_unpoison_range() as an
> > example).
> >
> > kasan_save_free_info is a KASAN internal function that should need
> > such a wrapper.
> >
> > For now, to make these patches simpler, you can keep kasan_enabled()
> > checks in mm/kasan/*, where they are now. Later we can move them to
> > include/linux/kasan.h with a separate patch.
>
> Yes, I'd like to revisit this in the next separate patch series.
Great!
But for now, please send a fix-up patch that removes the
__kasan_save_free_info() wrapper (or a v8? But I see that your series
is now in mm-stable, so I guess a separate fix-up patch is preferred).
I don't think you need a kasan_enabled() check in
kasan_save_free_info() at all. Both the higher level paths
(kasan_slab_free and kasan_mempool_poison_object) already contain this
check.
Thanks!
Powered by blists - more mailing lists