On Wed, Aug 20, 2025 at 7:35 AM Baoquan He <[email protected]> wrote: > > Currently only hw_tags mode of kasan can be enabled or disabled with > kernel parameter kasan=on|off for built kernel. For kasan generic and > sw_tags mode, there's no way to disable them once kernel is built. > This is not convenient sometime, e.g in system kdump is configured. > When the 1st kernel has KASAN enabled and crash triggered to switch to > kdump kernel, the generic or sw_tags mode will cost much extra memory > for kasan shadow while in fact it's meaningless to have kasan in kdump > kernel. > > So this patchset moves the kasan=on|off out of hw_tags scope and into > common code to make it visible in generic and sw_tags mode too. Then we > can add kasan=off in kdump kernel to reduce the unneeded meomry cost for > kasan.
Continuing the discussion on the previous version: so the unwanted extra memory usage is caused by the shadow memory for vmalloc allocations (as they get freed lazily)? This needs to be explained in the commit message. If so, would it help if we make the kasan.vmalloc command-line parameter work with the non-HW_TAGS modes (and make it do the same thing as disabling CONFIG_KASAN_VMALLOC)? What I don't like about introducing kasan=off for non-HW_TAGS modes is that this parameter does not actually disable KASAN. It just suppresses KASAN code for mapping proper shadow memory. But the compiler-added instrumentation is still executing (and I suspect this might break the inline instrumentation mode). Perhaps, we could instead add a new kasan.shadow=on/off parameter to make it more explicit that KASAN is not off, it's just that it stops mapping shadow memory. Dmitry, Alexander, Marco, do you have any opinion on kasan=off for non-HW_TAGS modes? On a side note, this series will need to be rebased onto Sabyrzhan's patches [1] - those are close to being ready. But perhaps let's wait for v7 first. [1] https://lore.kernel.org/all/[email protected]/
