Re: [PATCH v3 00/12] mm/kasan: make kasan=on|off work for all three modes

[Baoquan He <bhe@redhat.com>]

On 09/06/25 at 03:25pm, Andrey Konovalov wrote:
> On Fri, Sep 5, 2025 at 10:34 PM Andrey Konovalov <andreyknvl@gmail.com> wrote:
> >
> > Baoquan, I'd be in favor of implementing kasan.vmalloc=off instead of
> > kasan=off. This seems to both (almost) solve the RAM overhead problem
> > you're having (AFAIU) and also seems like a useful feature on its own
> > (similar to CONFIG_KASAN_VMALLOC=n but via command-line). The patches
> > to support kasan.vmalloc=off should also be orthogonal to the
> > Sabyrzhan's series.
> >
> > If you feel strongly that the ~1/8th RAM overhead (coming from the
> > physmap shadow and the slab redzones) is still unacceptable for your
> > use case (noting that the performance overhead (and the constant
> > silent detection of false-positive bugs) would still be there), I
> > think you can proceed with your series (unless someone else is
> > against).
> 
> Hm, just realized that kasan.vmalloc=off would probably break if
> CONFIG_VMAP_STACK is enabled: read-only shadow for vmalloc =>
> read-only shadow for stacks => stack instrumentation will try writing
> into read-only shadow and crash.
> 
> So I wonder if there's a way to avoid the lazy vmap freeing to deal
> with the RAM overhead.

That's a very key feature of vmalloc, lazy vmap freeing not only
integrate the virtual area freeing on one cpu at one time, but also
merge the areas and flush tlb at one time too. Please see
__purge_vmap_area_lazy() for the details. This can avoid performance
degradation when many vfree() are called.