From: Andrey Konovalov <andreyknvl@gmail.com>
To: Baoquan He <bhe@redhat.com>
Cc: Andrey Ryabinin <ryabinin.a.a@gmail.com>,
snovitoll@gmail.com, glider@google.com, dvyukov@google.com,
elver@google.com, linux-mm@kvack.org, 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,
christophe.leroy@csgroup.eu
Subject: Re: [PATCH v3 00/12] mm/kasan: make kasan=on|off work for all three modes
Date: Tue, 23 Sep 2025 19:49:40 +0200 [thread overview]
Message-ID: <CA+fCnZcWEuBerMeS4RCXQtged06MJhY=55KsYeJEOJn3K0psXQ@mail.gmail.com> (raw)
In-Reply-To: <aMfWz4gwFNMx7x82@MiWiFi-R3L-srv>
On Mon, Sep 15, 2025 at 11:05 AM Baoquan He <bhe@redhat.com> wrote:
>
> > 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).
>
> Yeah, that would be great if we can also avoid any not needed memory
> consumption for kdump.
Ack. Let's add support for kasan=off then.
But please describe it in detail in the KASAN documentation.
[...]
> When I made patch and posted, I didn't see Sabyrzhan's patches because I
> usually don't go through mm mailing list. If I saw his patch earlier, I
> would have suggested him to solve this at the same time.
>
> About Sabyrzhan's patch sereis, I have picked up part of his patches and
> credit the author to Sabyrzhan in below patchset.
>
> [PATCH 0/4] mm/kasan: remove kasan_arch_is_ready()
> https://lore.kernel.org/all/20250812130933.71593-1-bhe@redhat.com/T/#u
>
> About reposting of this series, do you think which one is preferred:
>
> 1) Firstly merge Sabyrzhan's patch series, I reverted them and apply for
> my patchset.
>
> 2) Credit the author of patch 1,2,3 of this patch series to Sabyrzhan
> too as below, because Sabyrzhan do the unification of the static keys
> usage and the KASAN initialization calls earlier:
Since the Sabyrzhan's patches are already in mm-stable (and I assume
will be merged during the next merge window), just rebase your changes
on top.
But also note that Sabyrzhan is planning to move out the
kasan_enabled() checks into include/linux/kasan.h (which is a clean-up
I would have also asked you to do with the kasan=off patches), so
maybe you should sync up with him wrt these changes.
Thanks!
next prev parent reply other threads:[~2025-09-23 17:49 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 ` [PATCH v3 00/12] mm/kasan: make kasan=on|off work " Andrey Konovalov
2025-09-04 8:11 ` 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 [this message]
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+fCnZcWEuBerMeS4RCXQtged06MJhY=55KsYeJEOJn3K0psXQ@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