Andrew Morton
unread,Jun 28, 2024, 10:31:08 PMJun 28Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to mm-co...@vger.kernel.org, vba...@suse.cz, sv...@linux.ibm.com, ros...@goodmis.org, roman.g...@linux.dev, rien...@google.com, pen...@kernel.org, mhir...@kernel.org, mark.r...@arm.com, kasa...@googlegroups.com, iamjoon...@lge.com, h...@linux.ibm.com, g...@linux.ibm.com, gli...@google.com, el...@google.com, dvy...@google.com, c...@linux.com, bornt...@linux.ibm.com, agor...@linux.ibm.com, 42.h...@gmail.com, i...@linux.ibm.com, ak...@linux-foundation.org
The quilt patch titled
Subject: s390/boot: add the KMSAN runtime stub
has been removed from the -mm tree. Its filename was
s390-boot-add-the-kmsan-runtime-stub.patch
This patch was dropped because it was merged into the mm-stable branch
of git://
git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Ilya Leoshkevich <
i...@linux.ibm.com>
Subject: s390/boot: add the KMSAN runtime stub
Date: Fri, 21 Jun 2024 13:35:08 +0200
It should be possible to have inline functions in the s390 header files,
which call kmsan_unpoison_memory(). The problem is that these header
files might be included by the decompressor, which does not contain KMSAN
runtime, causing linker errors.
Not compiling these calls if __SANITIZE_MEMORY__ is not defined - either
by changing kmsan-checks.h or at the call sites - may cause unintended
side effects, since calling these functions from an uninstrumented code
that is linked into the kernel is valid use case.
One might want to explicitly distinguish between the kernel and the
decompressor. Checking for a decompressor-specific #define is quite
heavy-handed, and will have to be done at all call sites.
A more generic approach is to provide a dummy kmsan_unpoison_memory()
definition. This produces some runtime overhead, but only when building
with CONFIG_KMSAN. The benefit is that it does not disturb the existing
KMSAN build logic and call sites don't need to be changed.
Link:
https://lkml.kernel.org/r/20240621113706...@linux.ibm.com
Signed-off-by: Ilya Leoshkevich <
i...@linux.ibm.com>
Reviewed-by: Alexander Potapenko <
gli...@google.com>
Cc: Alexander Gordeev <
agor...@linux.ibm.com>
Cc: Christian Borntraeger <
bornt...@linux.ibm.com>
Cc: Christoph Lameter <
c...@linux.com>
Cc: David Rientjes <
rien...@google.com>
Cc: Dmitry Vyukov <
dvy...@google.com>
Cc: Heiko Carstens <
h...@linux.ibm.com>
Cc: Hyeonggon Yoo <
42.h...@gmail.com>
Cc: Joonsoo Kim <
iamjoon...@lge.com>
Cc: <
kasa...@googlegroups.com>
Cc: Marco Elver <
el...@google.com>
Cc: Mark Rutland <
mark.r...@arm.com>
Cc: Masami Hiramatsu (Google) <
mhir...@kernel.org>
Cc: Pekka Enberg <
pen...@kernel.org>
Cc: Roman Gushchin <
roman.g...@linux.dev>
Cc: Steven Rostedt (Google) <
ros...@goodmis.org>
Cc: Sven Schnelle <
sv...@linux.ibm.com>
Cc: Vasily Gorbik <
g...@linux.ibm.com>
Cc: Vlastimil Babka <
vba...@suse.cz>
Signed-off-by: Andrew Morton <
ak...@linux-foundation.org>
---
arch/s390/boot/Makefile | 1 +
arch/s390/boot/kmsan.c | 6 ++++++
2 files changed, 7 insertions(+)
--- /dev/null
+++ a/arch/s390/boot/kmsan.c
@@ -0,0 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/kmsan-checks.h>
+
+void kmsan_unpoison_memory(const void *address, size_t size)
+{
+}
--- a/arch/s390/boot/Makefile~s390-boot-add-the-kmsan-runtime-stub
+++ a/arch/s390/boot/Makefile
@@ -44,6 +44,7 @@ obj-$(findstring y, $(CONFIG_PROTECTED_V
obj-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
obj-y += $(if $(CONFIG_KERNEL_UNCOMPRESSED),,decompressor.o) info.o
obj-$(CONFIG_KERNEL_ZSTD) += clz_ctz.o
+obj-$(CONFIG_KMSAN) += kmsan.o
obj-all := $(obj-y) piggy.o syms.o
targets := bzImage section_cmp.boot.data section_cmp.boot.preserved.data $(obj-y)
_
Patches currently in -mm which might be from
i...@linux.ibm.com are