From: Andrey Konovalov <andreyknvl@gmail.com>
To: Baoquan He <bhe@redhat.com>,
glider@google.com, dvyukov@google.com, elver@google.com
Cc: linux-mm@kvack.org, ryabinin.a.a@gmail.com,
vincenzo.frascino@arm.com, akpm@linux-foundation.org,
kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org,
kexec@lists.infradead.org, sj@kernel.org,
lorenzo.stoakes@oracle.com, snovitoll@gmail.com,
christophe.leroy@csgroup.eu
Subject: Re: [PATCH v3 00/12] mm/kasan: make kasan=on|off work for all three modes
Date: Wed, 3 Sep 2025 15:22:14 +0200 [thread overview]
Message-ID: <CA+fCnZdfv+D7sfRtWgbbFAmWExggzC2by8sDaK7hXfTS7viY8w@mail.gmail.com> (raw)
In-Reply-To: <20250820053459.164825-1-bhe@redhat.com>
On Wed, Aug 20, 2025 at 7:35 AM Baoquan He <bhe@redhat.com> 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/20250810125746.1105476-1-snovitoll@gmail.com/
next prev parent reply other threads:[~2025-09-03 13:22 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-20 5:34 Baoquan He
2025-08-20 5:34 ` [PATCH v3 01/12] mm/kasan: add conditional checks in functions to return directly if kasan is disabled Baoquan He
2025-08-20 5:34 ` [PATCH v3 02/12] mm/kasan: move kasan= code to common place Baoquan He
2025-08-20 5:34 ` [PATCH v3 03/12] mm/kasan/sw_tags: don't initialize kasan if it's disabled Baoquan He
2025-08-20 5:34 ` [PATCH v3 04/12] arch/arm: " Baoquan He
2025-08-20 5:34 ` [PATCH v3 05/12] arch/arm64: " Baoquan He
2025-08-20 5:34 ` [PATCH v3 06/12] arch/loongarch: " Baoquan He
2025-08-20 5:34 ` [PATCH v3 07/12] arch/powerpc: " Baoquan He
2025-08-20 5:34 ` [PATCH v3 08/12] arch/riscv: " Baoquan He
2025-08-20 5:34 ` [PATCH v3 09/12] arch/x86: " Baoquan He
2025-08-20 5:34 ` [PATCH v3 10/12] arch/xtensa: " Baoquan He
2025-08-20 5:34 ` [PATCH v3 11/12] arch/um: " Baoquan He
2025-08-20 5:34 ` [PATCH v3 12/12] mm/kasan: make kasan=on|off take effect for all three modes Baoquan He
2025-09-03 13:22 ` Andrey Konovalov [this message]
2025-09-04 8:11 ` [PATCH v3 00/12] mm/kasan: make kasan=on|off work " Baoquan He
2025-09-04 14:58 ` Andrey Konovalov
2025-09-05 17:12 ` Andrey Ryabinin
2025-09-05 18:08 ` Andrey Konovalov
2025-09-05 19:13 ` Christophe Leroy
2025-09-05 19:44 ` Andrey Konovalov
2025-09-05 20:34 ` Andrey Konovalov
2025-09-06 13:25 ` Andrey Konovalov
2025-09-15 5:37 ` Baoquan He
2025-09-15 9:05 ` Baoquan He
2025-09-23 17:49 ` Andrey Konovalov
2025-09-24 2:35 ` Baoquan He
2025-09-24 21:07 ` Sabyrzhan Tasbolatov
2025-09-25 6:20 ` Baoquan He
2025-10-14 5:27 ` Sabyrzhan Tasbolatov
2025-10-14 9:14 ` Baoquan He
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+fCnZdfv+D7sfRtWgbbFAmWExggzC2by8sDaK7hXfTS7viY8w@mail.gmail.com \
--to=andreyknvl@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=christophe.leroy@csgroup.eu \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=ryabinin.a.a@gmail.com \
--cc=sj@kernel.org \
--cc=snovitoll@gmail.com \
--cc=vincenzo.frascino@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox