linux-s390.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heiko Carstens <hca@linux.ibm.com>
To: Andrey Konovalov <andreyknvl@gmail.com>
Cc: Sabyrzhan Tasbolatov <snovitoll@gmail.com>,
	ryabinin.a.a@gmail.com, glider@google.com, dvyukov@google.com,
	vincenzo.frascino@arm.com, linux@armlinux.org.uk,
	catalin.marinas@arm.com, will@kernel.org, chenhuacai@kernel.org,
	kernel@xen0n.name, maddy@linux.ibm.com, mpe@ellerman.id.au,
	npiggin@gmail.com, christophe.leroy@csgroup.eu,
	paul.walmsley@sifive.com, palmer@dabbelt.com,
	aou@eecs.berkeley.edu, alex@ghiti.fr, gor@linux.ibm.com,
	agordeev@linux.ibm.com, borntraeger@linux.ibm.com,
	svens@linux.ibm.com, richard@nod.at,
	anton.ivanov@cambridgegreys.com, johannes@sipsolutions.net,
	dave.hansen@linux.intel.com, luto@kernel.org,
	peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com,
	bp@alien8.de, x86@kernel.org, hpa@zytor.com, chris@zankel.net,
	jcmvbkbc@gmail.com, akpm@linux-foundation.org, nathan@kernel.org,
	nick.desaulniers+lkml@gmail.com, morbo@google.com,
	justinstitt@google.com, arnd@arndb.de, rppt@kernel.org,
	geert@linux-m68k.org, mcgrof@kernel.org,
	guoweikang.kernel@gmail.com, tiwei.btw@antgroup.com,
	kevin.brodsky@arm.com, benjamin.berg@intel.com,
	kasan-dev@googlegroups.com, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, loongarch@lists.linux.dev,
	linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org,
	linux-s390@vger.kernel.org, linux-um@lists.infradead.org,
	linux-mm@kvack.org, llvm@lists.linux.dev
Subject: Re: [PATCH v2 00/11] kasan: unify kasan_arch_is_ready with kasan_enabled
Date: Tue, 1 Jul 2025 12:15:37 +0200	[thread overview]
Message-ID: <20250701101537.10162Aa0-hca@linux.ibm.com> (raw)
In-Reply-To: <CA+fCnZcGyTECP15VMSPh+duLmxNe=ApHfOnbAY3NqtFHZvceZw@mail.gmail.com>

> > > Another thing that needs careful consideration is whether it's
> > > possible to combine kasan_arch_is_ready() and kasan_enabled() into the
> > > same check logically at all. There's one issue mentioned in [1]:
> >
> > Hello,
> > I've removed kasan_arch_is_ready() at all in this series:
> > [PATCH v2 11/11] kasan: replace kasan_arch_is_ready with kasan_enabled
> >
> > Is it not what's expected by unification?
> 
> I guess the issue description diverged a bit from what needs to be
> done, sorry about that.
> 
> The core 2 things I wanted to address with the unification are:
> 
> 1. Avoid spraying kasan_arch_is_ready() throughout the KASAN
> implementation and move these checks into include/linux/kasan.h (and
> add __wrappers when required).
> 
> 2. Avoid architectures redefining the same kasan_enabled global
> variable/static key.
> 
> Initially, I thought that s/kasan_arch_is_ready/kasan_enabled + simply
> moving the calls into affected include/linux/kasan.h functions would
> be enough. But then, based on [1], turns out it's not that simple.
> 
> So now, I think we likely still need two separate checks/flags:
> kasan_enabled() that controls whether KASAN is enabled at all and
> kasan_arch_is_ready() that gets turned on by kasan_init() when shadow
> is initialized (should we rename it to kasan_shadow_initialized()?).
> But then we can still move kasan_arch_is_ready() into
> include/linux/kasan.h and use the proper combination of checks for
> each affected function before calling __wrappers. And we can still
> remove the duplicated flags/keys code from the arch code.

FWIW, as Alexander Gordeev already mentioned: this series breaks s390,
since the static_branch_enable() call in kasan_init_generic() is now
called way too early, and it isn't necessary at all. Which, as far as
I understand, may be the case for other architectures as well. s390
sets up the required KASAN mappings in the decompressor and can start
with KASAN enabled nearly from the beginning.

So something like below on top of this series would address
that. Given that this series is about to be reworked this is just for
illustration :)

diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 0c16dc443e2f..c2f51ac39a91 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -172,6 +172,7 @@ config S390
 	select HAVE_ARCH_JUMP_LABEL
 	select HAVE_ARCH_JUMP_LABEL_RELATIVE
 	select HAVE_ARCH_KASAN
+	select HAVE_ARCH_KASAN_EARLY
 	select HAVE_ARCH_KASAN_VMALLOC
 	select HAVE_ARCH_KCSAN
 	select HAVE_ARCH_KMSAN
diff --git a/include/linux/kasan-enabled.h b/include/linux/kasan-enabled.h
index 2436eb45cfee..049270a2269f 100644
--- a/include/linux/kasan-enabled.h
+++ b/include/linux/kasan-enabled.h
@@ -10,7 +10,11 @@
  * Global runtime flag. Starts ‘false’; switched to ‘true’ by
  * the appropriate kasan_init_*() once KASAN is fully initialized.
  */
+#ifdef CONFIG_HAVE_ARCH_KASAN_EARLY
+DECLARE_STATIC_KEY_TRUE(kasan_flag_enabled);
+#else
 DECLARE_STATIC_KEY_FALSE(kasan_flag_enabled);
+#endif
 
 static __always_inline bool kasan_enabled(void)
 {
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index f82889a830fa..1407374e83b9 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -4,6 +4,13 @@
 config HAVE_ARCH_KASAN
 	bool
 
+config HAVE_ARCH_KASAN_EARLY
+	bool
+	help
+	  Architectures should select this if KASAN mappings are setup in
+	  the decompressor and when the kernel can run very early with
+	  KASAN enabled.
+
 config HAVE_ARCH_KASAN_SW_TAGS
 	bool
 
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 0f3648335a6b..2aae0ce659b4 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -36,7 +36,11 @@
  * Definition of the unified static key declared in kasan-enabled.h.
  * This provides consistent runtime enable/disable across all KASAN modes.
  */
+#ifdef CONFIG_HAVE_ARCH_KASAN_EARLY
+DEFINE_STATIC_KEY_TRUE(kasan_flag_enabled);
+#else
 DEFINE_STATIC_KEY_FALSE(kasan_flag_enabled);
+#endif
 EXPORT_SYMBOL(kasan_flag_enabled);
 
 struct slab *kasan_addr_to_slab(const void *addr)
diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
index a3b112868be7..455376d5f1c3 100644
--- a/mm/kasan/generic.c
+++ b/mm/kasan/generic.c
@@ -42,7 +42,8 @@
  */
 void __init kasan_init_generic(void)
 {
-	static_branch_enable(&kasan_flag_enabled);
+	if (!IS_ENABLED(CONFIG_HAVE_ARCH_KASAN_EARLY))
+		static_branch_enable(&kasan_flag_enabled);
 
 	pr_info("KernelAddressSanitizer initialized (generic)\n");
 }

  reply	other threads:[~2025-07-01 10:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-26 15:31 [PATCH v2 00/11] kasan: unify kasan_arch_is_ready with kasan_enabled Sabyrzhan Tasbolatov
2025-06-26 15:31 ` [PATCH v2 01/11] kasan: unify static kasan_flag_enabled across modes Sabyrzhan Tasbolatov
2025-06-30 12:31   ` Alexander Gordeev
2025-06-30 14:39     ` Heiko Carstens
2025-06-30 15:23       ` Alexander Gordeev
2025-07-01  0:05     ` Andrew Morton
2025-06-26 15:31 ` [PATCH v2 02/11] kasan/arm64: call kasan_init_generic in kasan_init Sabyrzhan Tasbolatov
2025-06-26 15:31 ` [PATCH v2 03/11] kasan/arm: " Sabyrzhan Tasbolatov
2025-06-26 15:31 ` [PATCH v2 04/11] kasan/xtensa: " Sabyrzhan Tasbolatov
2025-06-26 15:31 ` [PATCH v2 05/11] kasan/loongarch: " Sabyrzhan Tasbolatov
2025-06-26 15:31 ` [PATCH v2 06/11] kasan/um: " Sabyrzhan Tasbolatov
2025-06-26 15:31 ` [PATCH v2 07/11] kasan/x86: " Sabyrzhan Tasbolatov
2025-06-26 15:31 ` [PATCH v2 08/11] kasan/s390: " Sabyrzhan Tasbolatov
2025-06-26 15:31 ` [PATCH v2 09/11] kasan/powerpc: " Sabyrzhan Tasbolatov
2025-06-26 15:31 ` [PATCH v2 10/11] kasan/riscv: " Sabyrzhan Tasbolatov
2025-06-26 15:31 ` [PATCH v2 11/11] kasan: replace kasan_arch_is_ready with kasan_enabled Sabyrzhan Tasbolatov
2025-06-28 10:56 ` [PATCH v2 00/11] kasan: unify " Andrey Konovalov
2025-06-28 13:25   ` Sabyrzhan Tasbolatov
2025-06-29 20:05     ` Andrey Konovalov
2025-07-01 10:15       ` Heiko Carstens [this message]
2025-07-01 10:25         ` Christophe Leroy
2025-07-01 13:37           ` Heiko Carstens
2025-06-28 11:26 ` Christophe Leroy

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=20250701101537.10162Aa0-hca@linux.ibm.com \
    --to=hca@linux.ibm.com \
    --cc=agordeev@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex@ghiti.fr \
    --cc=andreyknvl@gmail.com \
    --cc=anton.ivanov@cambridgegreys.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=arnd@arndb.de \
    --cc=benjamin.berg@intel.com \
    --cc=borntraeger@linux.ibm.com \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=chris@zankel.net \
    --cc=christophe.leroy@csgroup.eu \
    --cc=dave.hansen@linux.intel.com \
    --cc=dvyukov@google.com \
    --cc=geert@linux-m68k.org \
    --cc=glider@google.com \
    --cc=gor@linux.ibm.com \
    --cc=guoweikang.kernel@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jcmvbkbc@gmail.com \
    --cc=johannes@sipsolutions.net \
    --cc=justinstitt@google.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=kernel@xen0n.name \
    --cc=kevin.brodsky@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-um@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=llvm@lists.linux.dev \
    --cc=loongarch@lists.linux.dev \
    --cc=luto@kernel.org \
    --cc=maddy@linux.ibm.com \
    --cc=mcgrof@kernel.org \
    --cc=mingo@redhat.com \
    --cc=morbo@google.com \
    --cc=mpe@ellerman.id.au \
    --cc=nathan@kernel.org \
    --cc=nick.desaulniers+lkml@gmail.com \
    --cc=npiggin@gmail.com \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=peterz@infradead.org \
    --cc=richard@nod.at \
    --cc=rppt@kernel.org \
    --cc=ryabinin.a.a@gmail.com \
    --cc=snovitoll@gmail.com \
    --cc=svens@linux.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=tiwei.btw@antgroup.com \
    --cc=vincenzo.frascino@arm.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).