Messages in this thread |  | | From | Andrey Konovalov <> | | Date | Sat, 6 Sep 2025 15:25:15 +0200 | | Subject | Re: [PATCH v3 00/12] mm/kasan: make kasan=on|off work for all three modes |
| |
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.
|  |