On 09/03/25 at 03:22pm, Andrey Konovalov wrote: > 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.
Hmm, up to now, there are two parts of big amount of memory requiring for kernel as I observed. One is the direct memory mapping shadow of kasan, which is 1/8 of system RAM in generic mode and 1/16 of system RAM in sw_tags mode; the other is the shadow meomry for vmalloc which causes meomry big meomry usage in kdump kernel because of lazy vmap freeing. By introducing "kasan=off|on", if we specify 'kasan=off', the former is avoided by skipping the kasan_init(), and the latter is avoided by not build the vmalloc shadow for vmalloc. Yes, I totally agree with you, I should have put this in cover letter and the main patch log to explain it better. > > 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). I may not follow your saying it doesn't disable KASAN. In this patchset, not only do I disable the code for mapping shadow memory, but also I skip any KASAN checking. Please see change of check_region_inline() in mm/kasan/generic.c and kasan_check_range() in mm/kasan/sw_tags.c. It will skip any KASAN checking when accessing memory. Yeah, the compiler added instrumentation will be called, but the if (!kasan_enabled()) checking will decide if going further into KASAN code or just return directly. I tried inline mode on x86_64 and arm64, it works well when one reviewer said inline mode could cost much more memory, I don't see any breakage w or w/o kasan=off when this patchset applied.. > > 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. Hmm, as I explained at above, kasan=off will stop mapping shadow memory, and also stop executing KASAN code to poison/unpoison memory and check the shadow. It may be inappropriate to say it only stops mapping shadow. > > 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. I replied to Sabyrzhan's patchset, on top of this patchset, it's much easier and cleaner to remove kasan_arch_is_ready(). We don't need introduce CONFIG_ARCH_DEFER_KASAN. Please see below patchset which is based on this patchset introducing 'kasan=off|on' to genric|sw_tags mode. [PATCH 0/4] mm/kasan: remove kasan_arch_is_ready() https://lore.kernel.org/all/[email protected]/T/#u > > [1] https://lore.kernel.org/all/[email protected]/ > Thanks a lot for reviewing and feedback.
