On Fri, Sep 5, 2025 at 10:34 PM Andrey Konovalov <andreyk...@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.
