* [PATCH v3 8/8] livepatch: Add tests for klp-build toolchain
From: Song Liu @ 2026-02-26 0:54 UTC (permalink / raw)
To: live-patching
Cc: jpoimboe, jikos, mbenes, pmladek, joe.lawrence, kernel-team,
Song Liu
In-Reply-To: <20260226005436.379303-1-song@kernel.org>
Add selftests for the klp-build toolchain. This includes kernel side test
code and .patch files. The tests cover both livepatch to vmlinux and kernel
modules.
Check tools/testing/selftests/livepatch/test_patches/README for
instructions to run these tests.
Signed-off-by: Song Liu <song@kernel.org>
---
AI was used to wrote the test code and .patch files in this.
---
kernel/livepatch/Kconfig | 20 +++
kernel/livepatch/Makefile | 2 +
kernel/livepatch/tests/Makefile | 6 +
kernel/livepatch/tests/klp_test_module.c | 111 ++++++++++++++
kernel/livepatch/tests/klp_test_module.h | 8 +
kernel/livepatch/tests/klp_test_vmlinux.c | 138 ++++++++++++++++++
kernel/livepatch/tests/klp_test_vmlinux.h | 16 ++
kernel/livepatch/tests/klp_test_vmlinux_aux.c | 59 ++++++++
.../selftests/livepatch/test_patches/README | 15 ++
.../test_patches/klp_test_hash_change.patch | 30 ++++
.../test_patches/klp_test_module.patch | 18 +++
.../klp_test_nonstatic_to_static.patch | 40 +++++
.../klp_test_static_to_nonstatic.patch | 39 +++++
.../test_patches/klp_test_vmlinux.patch | 18 +++
14 files changed, 520 insertions(+)
create mode 100644 kernel/livepatch/tests/Makefile
create mode 100644 kernel/livepatch/tests/klp_test_module.c
create mode 100644 kernel/livepatch/tests/klp_test_module.h
create mode 100644 kernel/livepatch/tests/klp_test_vmlinux.c
create mode 100644 kernel/livepatch/tests/klp_test_vmlinux.h
create mode 100644 kernel/livepatch/tests/klp_test_vmlinux_aux.c
create mode 100644 tools/testing/selftests/livepatch/test_patches/README
create mode 100644 tools/testing/selftests/livepatch/test_patches/klp_test_hash_change.patch
create mode 100644 tools/testing/selftests/livepatch/test_patches/klp_test_module.patch
create mode 100644 tools/testing/selftests/livepatch/test_patches/klp_test_nonstatic_to_static.patch
create mode 100644 tools/testing/selftests/livepatch/test_patches/klp_test_static_to_nonstatic.patch
create mode 100644 tools/testing/selftests/livepatch/test_patches/klp_test_vmlinux.patch
diff --git a/kernel/livepatch/Kconfig b/kernel/livepatch/Kconfig
index 4c0a9c18d0b2..852049601389 100644
--- a/kernel/livepatch/Kconfig
+++ b/kernel/livepatch/Kconfig
@@ -30,3 +30,23 @@ config KLP_BUILD
select OBJTOOL
help
Enable klp-build support
+
+config KLP_TEST
+ bool "Livepatch test code"
+ depends on LIVEPATCH
+ help
+ Dummy kernel code for testing the klp-build livepatch toolchain.
+ Provides built-in vmlinux functions with sysfs interfaces for
+ verifying livepatches.
+
+ If unsure, say N.
+
+config KLP_TEST_MODULE
+ tristate "Livepatch test module (klp_test_module)"
+ depends on KLP_TEST && m
+ help
+ Test module for livepatch testing. Dummy kernel module for
+ testing the klp-build toolchain. Provides sysfs interfaces for
+ verifying livepatches.
+
+ If unsure, say N.
diff --git a/kernel/livepatch/Makefile b/kernel/livepatch/Makefile
index cf03d4bdfc66..751080a62cec 100644
--- a/kernel/livepatch/Makefile
+++ b/kernel/livepatch/Makefile
@@ -2,3 +2,5 @@
obj-$(CONFIG_LIVEPATCH) += livepatch.o
livepatch-objs := core.o patch.o shadow.o state.o transition.o
+
+obj-$(CONFIG_KLP_TEST) += tests/
diff --git a/kernel/livepatch/tests/Makefile b/kernel/livepatch/tests/Makefile
new file mode 100644
index 000000000000..82ae48f54abe
--- /dev/null
+++ b/kernel/livepatch/tests/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-y += klp_test_vmlinux_all.o
+obj-$(CONFIG_KLP_TEST_MODULE) += klp_test_module.o
+
+klp_test_vmlinux_all-y := klp_test_vmlinux.o \
+ klp_test_vmlinux_aux.o
diff --git a/kernel/livepatch/tests/klp_test_module.c b/kernel/livepatch/tests/klp_test_module.c
new file mode 100644
index 000000000000..25cefbe36a2b
--- /dev/null
+++ b/kernel/livepatch/tests/klp_test_module.c
@@ -0,0 +1,111 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * klp_test_module.c - Single-file test module for livepatch/klp-build testing
+ *
+ * Copyright (C) 2026 Meta Platforms, Inc. and affiliates.
+ */
+
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/kobject.h>
+#include <linux/sysfs.h>
+#include <linux/string.h>
+#include "klp_test_module.h"
+#include "klp_test_vmlinux.h"
+
+static int klp_test_module_var1;
+static int klp_test_module_var2;
+
+static noinline ssize_t __klp_test_module_func1(char *buf, int len)
+{
+ ssize_t ret = 0;
+ int i;
+
+ for (i = 0; i < len; i++)
+ klp_test_module_var1 += i;
+
+ if (klp_test_module_var1 > 1000)
+ klp_test_module_var1 = 0;
+
+ ret = sysfs_emit(buf, "klp_test_module_func1 unpatched %d\n",
+ klp_test_module_var1);
+ return ret;
+}
+
+ssize_t klp_test_module_func1(char *buf, int len)
+{
+ return __klp_test_module_func1(buf, len);
+}
+EXPORT_SYMBOL_GPL(klp_test_module_func1);
+
+static noinline ssize_t __klp_test_module_func2(char *buf, int len)
+{
+ ssize_t ret = 0;
+ int i;
+
+ for (i = 0; i < len; i++)
+ klp_test_module_var2 += i * 2;
+
+ if (klp_test_module_var2 > 1000)
+ klp_test_module_var2 = 0;
+
+ ret = sysfs_emit(buf, "klp_test_module_func2 unpatched %d\n",
+ klp_test_module_var2);
+ return ret;
+}
+
+ssize_t klp_test_module_func2(char *buf, int len)
+{
+ return __klp_test_module_func2(buf, len);
+}
+EXPORT_SYMBOL_GPL(klp_test_module_func2);
+
+static ssize_t func1_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return klp_test_module_func1(buf, 5);
+}
+
+static ssize_t func2_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return klp_test_module_func2(buf, 5);
+}
+
+static struct kobj_attribute func1_attr = __ATTR_RO(func1);
+static struct kobj_attribute func2_attr = __ATTR_RO(func2);
+
+static struct attribute *klp_test_module_attrs[] = {
+ &func1_attr.attr,
+ &func2_attr.attr,
+ NULL,
+};
+
+static const struct attribute_group klp_test_module_attr_group = {
+ .attrs = klp_test_module_attrs,
+};
+
+static struct kobject *klp_test_module_kobj;
+
+static int __init klp_test_module_init(void)
+{
+ klp_test_module_kobj = kobject_create_and_add("module",
+ klp_test_kobj);
+ if (!klp_test_module_kobj)
+ return -ENOMEM;
+
+ return sysfs_create_group(klp_test_module_kobj,
+ &klp_test_module_attr_group);
+}
+
+static void __exit klp_test_module_exit(void)
+{
+ sysfs_remove_group(klp_test_module_kobj, &klp_test_module_attr_group);
+ kobject_put(klp_test_module_kobj);
+}
+
+module_init(klp_test_module_init);
+module_exit(klp_test_module_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("Livepatch single-file test module");
diff --git a/kernel/livepatch/tests/klp_test_module.h b/kernel/livepatch/tests/klp_test_module.h
new file mode 100644
index 000000000000..56a766f4744b
--- /dev/null
+++ b/kernel/livepatch/tests/klp_test_module.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+#ifndef _KLP_TEST_MODULE_H
+#define _KLP_TEST_MODULE_H
+
+ssize_t klp_test_module_func1(char *buf, int len);
+ssize_t klp_test_module_func2(char *buf, int len);
+
+#endif /* _KLP_TEST_MODULE_H */
diff --git a/kernel/livepatch/tests/klp_test_vmlinux.c b/kernel/livepatch/tests/klp_test_vmlinux.c
new file mode 100644
index 000000000000..bd4157ea97c0
--- /dev/null
+++ b/kernel/livepatch/tests/klp_test_vmlinux.c
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * klp_test_vmlinux.c - Dummy built-in code for livepatch/klp-build testing
+ *
+ * Copyright (C) 2026 Meta Platforms, Inc. and affiliates.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/kobject.h>
+#include <linux/sysfs.h>
+#include <linux/init.h>
+#include <linux/string.h>
+#include "klp_test_vmlinux.h"
+
+static int klp_test_vmlinux_var1;
+static int klp_test_vmlinux_var2;
+
+static noinline int __helper(int x, int len)
+{
+ int i, sum = x;
+
+ for (i = 0; i < len; i++)
+ sum += i + 5;
+ if (sum > 1000)
+ sum = 0;
+ return sum;
+}
+
+static noinline ssize_t __klp_test_vmlinux_func1(char *buf, int len)
+{
+ ssize_t ret = 0;
+
+ klp_test_vmlinux_var1 = __helper(klp_test_vmlinux_var1, len);
+
+ ret = sysfs_emit(buf, "klp_test_vmlinux_func1 unpatched %d\n",
+ klp_test_vmlinux_var1);
+ return ret;
+}
+
+ssize_t klp_test_vmlinux_func1(char *buf, int len)
+{
+ return __klp_test_vmlinux_func1(buf, len);
+}
+EXPORT_SYMBOL_GPL(klp_test_vmlinux_func1);
+
+static noinline ssize_t __klp_test_vmlinux_func2(char *buf, int len)
+{
+ ssize_t ret = 0;
+ int i;
+
+ for (i = 0; i < len; i++)
+ klp_test_vmlinux_var2 += i * 2;
+
+ if (klp_test_vmlinux_var2 > 1000)
+ klp_test_vmlinux_var2 = 0;
+
+ ret = sysfs_emit(buf, "klp_test_vmlinux_func2 unpatched %d\n",
+ klp_test_vmlinux_var2);
+ return ret;
+}
+
+ssize_t klp_test_vmlinux_func2(char *buf, int len)
+{
+ return __klp_test_vmlinux_func2(buf, len);
+}
+EXPORT_SYMBOL_GPL(klp_test_vmlinux_func2);
+
+static ssize_t vmlinux_func1_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return klp_test_vmlinux_func1(buf, 5);
+}
+
+static ssize_t vmlinux_func2_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return klp_test_vmlinux_func2(buf, 5);
+}
+
+static struct kobj_attribute vmlinux_func1_attr = __ATTR_RO(vmlinux_func1);
+static struct kobj_attribute vmlinux_func2_attr = __ATTR_RO(vmlinux_func2);
+
+static struct attribute *klp_test_attrs[] = {
+ &vmlinux_func1_attr.attr,
+ &vmlinux_func2_attr.attr,
+ NULL,
+};
+
+static const struct attribute_group klp_test_attr_group = {
+ .attrs = klp_test_attrs,
+};
+
+static struct kobject *klp_test_vmlinux_kobj;
+struct kobject *klp_test_kobj;
+EXPORT_SYMBOL_GPL(klp_test_kobj);
+
+static int __init klp_test_vmlinux_init(void)
+{
+ int ret;
+
+ klp_test_kobj = kobject_create_and_add("klp_test", kernel_kobj);
+ if (!klp_test_kobj)
+ return -ENOMEM;
+
+ klp_test_vmlinux_kobj = kobject_create_and_add("vmlinux", klp_test_kobj);
+ if (!klp_test_vmlinux_kobj) {
+ kobject_put(klp_test_kobj);
+ return -ENOMEM;
+ }
+
+ ret = sysfs_create_group(klp_test_vmlinux_kobj, &klp_test_attr_group);
+ if (ret)
+ goto err_group;
+
+ ret = klp_test_vmlinux_aux_init(klp_test_vmlinux_kobj);
+ if (ret)
+ goto err_aux;
+
+ return 0;
+
+err_aux:
+ sysfs_remove_group(klp_test_vmlinux_kobj, &klp_test_attr_group);
+err_group:
+ kobject_put(klp_test_vmlinux_kobj);
+ kobject_put(klp_test_kobj);
+ return ret;
+}
+
+static void __exit klp_test_vmlinux_exit(void)
+{
+ klp_test_vmlinux_aux_exit(klp_test_vmlinux_kobj);
+ sysfs_remove_group(klp_test_vmlinux_kobj, &klp_test_attr_group);
+ kobject_put(klp_test_vmlinux_kobj);
+ kobject_put(klp_test_kobj);
+}
+
+late_initcall(klp_test_vmlinux_init);
diff --git a/kernel/livepatch/tests/klp_test_vmlinux.h b/kernel/livepatch/tests/klp_test_vmlinux.h
new file mode 100644
index 000000000000..56d9f7b6d350
--- /dev/null
+++ b/kernel/livepatch/tests/klp_test_vmlinux.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+#ifndef _KLP_TEST_VMLINUX_H
+#define _KLP_TEST_VMLINUX_H
+
+#include <linux/kobject.h>
+
+extern struct kobject *klp_test_kobj;
+
+ssize_t klp_test_vmlinux_func1(char *buf, int len);
+ssize_t klp_test_vmlinux_func2(char *buf, int len);
+ssize_t klp_test_vmlinux_func3(char *buf, int len);
+
+int klp_test_vmlinux_aux_init(struct kobject *parent);
+void klp_test_vmlinux_aux_exit(struct kobject *parent);
+
+#endif /* _KLP_TEST_VMLINUX_H */
diff --git a/kernel/livepatch/tests/klp_test_vmlinux_aux.c b/kernel/livepatch/tests/klp_test_vmlinux_aux.c
new file mode 100644
index 000000000000..1d76b0308a11
--- /dev/null
+++ b/kernel/livepatch/tests/klp_test_vmlinux_aux.c
@@ -0,0 +1,59 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * klp_test_vmlinux_aux.c - Auxiliary built-in code for livepatch/klp-build
+ * testing. This file has its own static __helper()
+ * to test ThinLTO .llvm.<hash> suffix handling.
+ *
+ * Copyright (C) 2026 Meta Platforms, Inc. and affiliates.
+ */
+
+#include <linux/kernel.h>
+#include <linux/kobject.h>
+#include <linux/sysfs.h>
+#include <linux/string.h>
+#include "klp_test_vmlinux.h"
+
+static int klp_test_vmlinux_var3;
+
+static noinline int __helper(int x, int len)
+{
+ int i, sum = x;
+
+ for (i = 0; i < len; i++)
+ sum += i + 10;
+ if (sum > 1000)
+ sum = 0;
+ return sum;
+}
+
+static noinline ssize_t __klp_test_vmlinux_func3(char *buf, int len)
+{
+ klp_test_vmlinux_var3 = __helper(klp_test_vmlinux_var3, len);
+
+ return sysfs_emit(buf, "klp_test_vmlinux_func3 unpatched %d\n",
+ klp_test_vmlinux_var3);
+}
+
+ssize_t klp_test_vmlinux_func3(char *buf, int len)
+{
+ return __klp_test_vmlinux_func3(buf, len);
+}
+EXPORT_SYMBOL_GPL(klp_test_vmlinux_func3);
+
+static ssize_t vmlinux_func3_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+{
+ return klp_test_vmlinux_func3(buf, 5);
+}
+
+static struct kobj_attribute vmlinux_func3_attr = __ATTR_RO(vmlinux_func3);
+
+int klp_test_vmlinux_aux_init(struct kobject *parent)
+{
+ return sysfs_create_file(parent, &vmlinux_func3_attr.attr);
+}
+
+void klp_test_vmlinux_aux_exit(struct kobject *parent)
+{
+ sysfs_remove_file(parent, &vmlinux_func3_attr.attr);
+}
diff --git a/tools/testing/selftests/livepatch/test_patches/README b/tools/testing/selftests/livepatch/test_patches/README
new file mode 100644
index 000000000000..8266348aab57
--- /dev/null
+++ b/tools/testing/selftests/livepatch/test_patches/README
@@ -0,0 +1,15 @@
+This is folder contains patches to test the klp-build toolchain.
+
+To run the test:
+
+1. Enable CONFIG_KLP_TEST and CONFIG_KLP_TEST_MODULE, and build the kernel.
+
+2. Build these patches with:
+
+ ./scripts/livepatch/klp-build tools/testing/selftests/livepatch/test_patches/*.patch
+
+3. Verify the correctness with:
+
+ modprobe klp_test_module
+ kpatch load livepatch-patch.ko
+ grep -q unpatched /sys/kernel/klp_test/*/* && echo FAIL || echo PASS
diff --git a/tools/testing/selftests/livepatch/test_patches/klp_test_hash_change.patch b/tools/testing/selftests/livepatch/test_patches/klp_test_hash_change.patch
new file mode 100644
index 000000000000..609d54d6d6f6
--- /dev/null
+++ b/tools/testing/selftests/livepatch/test_patches/klp_test_hash_change.patch
@@ -0,0 +1,30 @@
+Test ThinLTO .llvm.<hash> suffix handling.
+
+Modify a static __helper() function whose body change causes its
+.llvm.<hash> suffix to change under ThinLTO. Both klp_test_vmlinux.c
+and klp_test_vmlinux_aux.c define static __helper() with different
+bodies, so ThinLTO promotes both to globals with different hashes.
+This patch changes the __helper() in the aux file, which changes its
+hash, and klp-build must correctly match the old and new symbols.
+
+diff --git i/kernel/livepatch/tests/klp_test_vmlinux_aux.c w/kernel/livepatch/tests/klp_test_vmlinux_aux.c
+--- i/kernel/livepatch/tests/klp_test_vmlinux_aux.c
++++ w/kernel/livepatch/tests/klp_test_vmlinux_aux.c
+@@ -20,7 +20,7 @@
+ int i, sum = x;
+
+ for (i = 0; i < len; i++)
+- sum += i + 10;
++ sum += i * 2 + 10;
+ if (sum > 1000)
+ sum = 0;
+ return sum;
+@@ -30,7 +30,7 @@
+ {
+ klp_test_vmlinux_var3 = __helper(klp_test_vmlinux_var3, len);
+
+- return sysfs_emit(buf, "klp_test_vmlinux_func3 unpatched %d\n",
++ return sysfs_emit(buf, "klp_test_vmlinux_func3 hash_patched %d\n",
+ klp_test_vmlinux_var3);
+ }
+
diff --git a/tools/testing/selftests/livepatch/test_patches/klp_test_module.patch b/tools/testing/selftests/livepatch/test_patches/klp_test_module.patch
new file mode 100644
index 000000000000..d86e75618136
--- /dev/null
+++ b/tools/testing/selftests/livepatch/test_patches/klp_test_module.patch
@@ -0,0 +1,18 @@
+Test basic module patching.
+
+Patch a loadable module function to verify that klp-build can generate
+a livepatch for module code. Changes __klp_test_module_func1() output
+from "unpatched" to "patched".
+
+diff --git i/kernel/livepatch/tests/klp_test_module.c w/kernel/livepatch/tests/klp_test_module.c
+--- i/kernel/livepatch/tests/klp_test_module.c
++++ w/kernel/livepatch/tests/klp_test_module.c
+@@ -27,7 +27,7 @@
+ if (klp_test_module_var1 > 1000)
+ klp_test_module_var1 = 0;
+
+- ret = sysfs_emit(buf, "klp_test_module_func1 unpatched %d\n",
++ ret = sysfs_emit(buf, "klp_test_module_func1 patched %d\n",
+ klp_test_module_var1);
+ return ret;
+ }
diff --git a/tools/testing/selftests/livepatch/test_patches/klp_test_nonstatic_to_static.patch b/tools/testing/selftests/livepatch/test_patches/klp_test_nonstatic_to_static.patch
new file mode 100644
index 000000000000..f26711c6bfac
--- /dev/null
+++ b/tools/testing/selftests/livepatch/test_patches/klp_test_nonstatic_to_static.patch
@@ -0,0 +1,40 @@
+Test nonstatic-to-static symbol change.
+
+Change klp_test_module_func2() from nonstatic (global) to static and
+remove its EXPORT_SYMBOL_GPL. Also remove its declaration from the
+header file. This tests klp-build's ability to handle symbol visibility
+changes where a function that was originally global becomes static in
+the patched kernel.
+
+diff --git i/kernel/livepatch/tests/klp_test_module.c w/kernel/livepatch/tests/klp_test_module.c
+--- i/kernel/livepatch/tests/klp_test_module.c
++++ w/kernel/livepatch/tests/klp_test_module.c
+@@ -49,16 +49,15 @@
+ if (klp_test_module_var2 > 1000)
+ klp_test_module_var2 = 0;
+
+- ret = sysfs_emit(buf, "klp_test_module_func2 unpatched %d\n",
++ ret = sysfs_emit(buf, "klp_test_module_func2 patched_nts %d\n",
+ klp_test_module_var2);
+ return ret;
+ }
+
+-ssize_t klp_test_module_func2(char *buf, int len)
++static noinline ssize_t klp_test_module_func2(char *buf, int len)
+ {
+ return __klp_test_module_func2(buf, len);
+ }
+-EXPORT_SYMBOL_GPL(klp_test_module_func2);
+
+ static ssize_t func1_show(struct kobject *kobj,
+ struct kobj_attribute *attr, char *buf)
+diff --git i/kernel/livepatch/tests/klp_test_module.h w/kernel/livepatch/tests/klp_test_module.h
+--- i/kernel/livepatch/tests/klp_test_module.h
++++ w/kernel/livepatch/tests/klp_test_module.h
+@@ -3,6 +3,5 @@
+ #define _KLP_TEST_MODULE_H
+
+ ssize_t klp_test_module_func1(char *buf, int len);
+-ssize_t klp_test_module_func2(char *buf, int len);
+
+ #endif /* _KLP_TEST_MODULE_H */
diff --git a/tools/testing/selftests/livepatch/test_patches/klp_test_static_to_nonstatic.patch b/tools/testing/selftests/livepatch/test_patches/klp_test_static_to_nonstatic.patch
new file mode 100644
index 000000000000..673f6c42f698
--- /dev/null
+++ b/tools/testing/selftests/livepatch/test_patches/klp_test_static_to_nonstatic.patch
@@ -0,0 +1,39 @@
+Test static-to-nonstatic symbol change.
+
+Change __klp_test_vmlinux_func2() from static to nonstatic (global).
+This tests klp-build's ability to handle symbol visibility changes
+where a function that was originally static becomes globally visible
+in the patched kernel.
+
+diff --git i/kernel/livepatch/tests/klp_test_vmlinux.c w/kernel/livepatch/tests/klp_test_vmlinux.c
+--- i/kernel/livepatch/tests/klp_test_vmlinux.c
++++ w/kernel/livepatch/tests/klp_test_vmlinux.c
+@@ -44,7 +44,7 @@
+ }
+ EXPORT_SYMBOL_GPL(klp_test_vmlinux_func1);
+
+-static noinline ssize_t __klp_test_vmlinux_func2(char *buf, int len)
++noinline ssize_t __klp_test_vmlinux_func2(char *buf, int len)
+ {
+ ssize_t ret = 0;
+ int i;
+@@ -55,7 +55,7 @@
+ if (klp_test_vmlinux_var2 > 1000)
+ klp_test_vmlinux_var2 = 0;
+
+- ret = sysfs_emit(buf, "klp_test_vmlinux_func2 unpatched %d\n",
++ ret = sysfs_emit(buf, "klp_test_vmlinux_func2 patched_stn %d\n",
+ klp_test_vmlinux_var2);
+ return ret;
+ }
+diff --git i/kernel/livepatch/tests/klp_test_vmlinux.h w/kernel/livepatch/tests/klp_test_vmlinux.h
+--- i/kernel/livepatch/tests/klp_test_vmlinux.h
++++ w/kernel/livepatch/tests/klp_test_vmlinux.h
+@@ -9,6 +9,7 @@
+ ssize_t klp_test_vmlinux_func1(char *buf, int len);
+ ssize_t klp_test_vmlinux_func2(char *buf, int len);
+ ssize_t klp_test_vmlinux_func3(char *buf, int len);
++ssize_t __klp_test_vmlinux_func2(char *buf, int len);
+
+ int klp_test_vmlinux_aux_init(struct kobject *parent);
+ void klp_test_vmlinux_aux_exit(struct kobject *parent);
diff --git a/tools/testing/selftests/livepatch/test_patches/klp_test_vmlinux.patch b/tools/testing/selftests/livepatch/test_patches/klp_test_vmlinux.patch
new file mode 100644
index 000000000000..8b1d91381728
--- /dev/null
+++ b/tools/testing/selftests/livepatch/test_patches/klp_test_vmlinux.patch
@@ -0,0 +1,18 @@
+Test basic vmlinux patching.
+
+Patch a built-in vmlinux function to verify that klp-build can generate
+a livepatch for vmlinux code. Changes __klp_test_vmlinux_func1() output
+from "unpatched" to "patched".
+
+diff --git i/kernel/livepatch/tests/klp_test_vmlinux.c w/kernel/livepatch/tests/klp_test_vmlinux.c
+--- i/kernel/livepatch/tests/klp_test_vmlinux.c
++++ w/kernel/livepatch/tests/klp_test_vmlinux.c
+@@ -33,7 +33,7 @@
+
+ klp_test_vmlinux_var1 = __helper(klp_test_vmlinux_var1, len);
+
+- ret = sysfs_emit(buf, "klp_test_vmlinux_func1 unpatched %d\n",
++ ret = sysfs_emit(buf, "klp_test_vmlinux_func1 patched %d\n",
+ klp_test_vmlinux_var1);
+ return ret;
+ }
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] kernel/trace/ftrace: introduce ftrace module notifier
From: Miroslav Benes @ 2026-02-26 10:51 UTC (permalink / raw)
To: Song Chen
Cc: Steven Rostedt, mcgrof, petr.pavlu, da.gomez, samitolvanen,
atomlin, mhiramat, mark.rutland, mathieu.desnoyers, linux-modules,
linux-kernel, linux-trace-kernel, live-patching
In-Reply-To: <e18ed5f4-3917-46e7-bca9-78063e6e4457@189.cn>
[-- Attachment #1: Type: text/plain, Size: 3620 bytes --]
Hi,
+ Cc: live-patching@vger.kernel.org
On Thu, 26 Feb 2026, Song Chen wrote:
> Hi,
>
> 在 2026/2/26 08:27, Steven Rostedt 写道:
> > On Wed, 25 Feb 2026 13:46:39 +0800
> > chensong_2000@189.cn wrote:
> >
> >> From: Song Chen <chensong_2000@189.cn>
> >>
> >> Like kprobe, fprobe and btf, this patch attempts to introduce
> >> a notifier_block for ftrace to decouple its initialization from
> >> load_module.
> >>
> >> Below is the table of ftrace fucntions calls in different
> >> module state:
> >>
> >> MODULE_STATE_UNFORMED ftrace_module_init
> >> MODULE_STATE_COMING ftrace_module_enable
> >> MODULE_STATE_LIVE ftrace_free_mem
> >> MODULE_STATE_GOING ftrace_release_mod
> >>
> >> Unlike others, ftrace module notifier must take care of state
> >> MODULE_STATE_UNFORMED to ensure calling ftrace_module_init
> >> before complete_formation which changes module's text property.
> >>
> >> That pretty much remains same logic with its original design,
> >> the only thing that changes is blocking_notifier_call_chain
> >> (MODULE_STATE_GOING) has to be moved from coming_cleanup to
> >> ddebug_cleanup in function load_module to ensure
> >> ftrace_release_mod is invoked in case complete_formation fails.
> >>
> >> Signed-off-by: Song Chen <chensong_2000@189.cn>
> >> ---
> >> kernel/module/main.c | 14 ++++----------
> >> kernel/trace/ftrace.c | 37 +++++++++++++++++++++++++++++++++++++
> >> 2 files changed, 41 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/kernel/module/main.c b/kernel/module/main.c
> >> index 710ee30b3bea..5dc0a980e9bd 100644
> >> --- a/kernel/module/main.c
> >> +++ b/kernel/module/main.c
> >> @@ -45,7 +45,6 @@
> >> #include <linux/license.h>
> >> #include <asm/sections.h>
> >> #include <linux/tracepoint.h>
> >> -#include <linux/ftrace.h>
> >> #include <linux/livepatch.h>
> >> #include <linux/async.h>
> >> #include <linux/percpu.h>
> >> @@ -836,7 +835,6 @@ SYSCALL_DEFINE2(delete_module, const char __user *,
> >> name_user,
> >> blocking_notifier_call_chain(&module_notify_list,
> >> MODULE_STATE_GOING, mod);
> >> klp_module_going(mod);
> >> - ftrace_release_mod(mod);
> >
> > Is the above safe? klp uses ftrace. That means klp_module_going() may
> > need to be called before ftrace_release_mod(). That said, I wonder if
> > klp_module_going() could be moved into ftrace_release_mod()?
> >
> >>
>
> I didn't test with klp, so i'm not sure if it's safe. But i consider klp is
> the other part which should be decoupled after ftrace and klp should introduce
> its own notifier.
>
> If klp_module_going must be running before ftrace_release_mod, i can try to
> use priority in notifier_block to ensure their order.
>
> Let me see if there is any way to use notifier and remain below calling
> sequence:
>
> ftrace_module_enable
> klp_module_coming
> blocking_notifier_call_chain_robust(MODULE_STATE_COMING)
>
> blocking_notifier_call_chain(MODULE_STATE_GOING)
> klp_module_going
> ftrace_release_mod
Both klp and ftrace used module notifiers in the past. We abandoned that
and opted for direct calls due to issues with ordering at the time. I do
not have the list of problems at hand but I remember it was very fragile.
See commits 7dcd182bec27 ("ftrace/module: remove ftrace module
notifier"), 7e545d6eca20 ("livepatch/module: remove livepatch module
notifier") and their surroundings.
So unless there is a reason for the change (which should be then carefully
reviewed and properly tested), I would prefer to keep it as is. What is
the motivation? I am failing to find it in the commit log.
Regards,
Miroslav
^ permalink raw reply
* Re: [PATCH 1/2] selftests: livepatch: test-ftrace: livepatch a traced function
From: Miroslav Benes @ 2026-02-26 12:14 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Josh Poimboeuf, Jiri Kosina, Petr Mladek, Joe Lawrence,
Shuah Khan, live-patching, linux-kselftest, linux-kernel
In-Reply-To: <20260220-lp-test-trace-v1-1-4b6703cd01a6@suse.com>
Hi,
On Fri, 20 Feb 2026, Marcos Paulo de Souza wrote:
> This is basically the inverse case of commit 474eecc882ae
> ("selftests: livepatch: test if ftrace can trace a livepatched function")
> but ensuring that livepatch would work on a traced function.
>
> Signed-off-by: Marcos Paulo de Souza <mpdesouza@suse.com>
with the typo fix that Joe mentioned
Acked-by: Miroslav Benes <mbenes@suse.cz>
M
^ permalink raw reply
* Re: [PATCH 2/2] selftests: livepatch: functions.sh: Workaround heredoc on older bash
From: Miroslav Benes @ 2026-02-26 12:40 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: Joe Lawrence, Josh Poimboeuf, Jiri Kosina, Petr Mladek,
Shuah Khan, live-patching, linux-kselftest, linux-kernel
In-Reply-To: <5ca16692b304185df695e517434b16e59cb15a42.camel@suse.com>
[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]
Hi,
On Mon, 23 Feb 2026, Marcos Paulo de Souza wrote:
> On Mon, 2026-02-23 at 10:42 -0500, Joe Lawrence wrote:
> > On Fri, Feb 20, 2026 at 11:12:34AM -0300, Marcos Paulo de Souza
> > wrote:
> > > When running current selftests on older distributions like SLE12-
> > > SP5 that
> > > contains an older bash trips over heredoc. Convert it to plain echo
> > > calls, which ends up with the same result.
> > >
> >
> > Acked-by: Joe Lawrence <joe.lawrence@redhat.com>
>
> Thanks for the review Joe!
>
> >
> > Just curious, what's the bash/heredoc issue? All I could find via
> > google search was perhaps something to do with the temporary file
> > implementation under the hood.
>
> # ./test-ftrace.sh
> cat: -: No such file or directory
> TEST: livepatch interaction with ftrace_enabled sysctl ... ^CQEMU:
> Terminated
I cannot reproduce it locally on SLE12-SP5. The patched test-ftrace.sh
runs smoothly without 2/2.
linux:~/linux/tools/testing/selftests/livepatch # ./test-ftrace.sh
TEST: livepatch interaction with ftrace_enabled sysctl ... ok
TEST: trace livepatched function and check that the live patch remains in effect ... ok
TEST: livepatch a traced function and check that the live patch remains in effect ... ok
GNU bash, version 4.3.48(1)-release (x86_64-suse-linux-gnu)
Does "set -x" in the script give you anything interesting?
Miroslav
^ permalink raw reply
* Re: [PATCH 2/2] selftests: livepatch: functions.sh: Workaround heredoc on older bash
From: Marcos Paulo de Souza @ 2026-02-26 14:34 UTC (permalink / raw)
To: Miroslav Benes
Cc: Joe Lawrence, Josh Poimboeuf, Jiri Kosina, Petr Mladek,
Shuah Khan, live-patching, linux-kselftest, linux-kernel
In-Reply-To: <alpine.LSU.2.21.2602261337170.5739@pobox.suse.cz>
On Thu, 2026-02-26 at 13:40 +0100, Miroslav Benes wrote:
> Hi,
>
> On Mon, 23 Feb 2026, Marcos Paulo de Souza wrote:
>
> > On Mon, 2026-02-23 at 10:42 -0500, Joe Lawrence wrote:
> > > On Fri, Feb 20, 2026 at 11:12:34AM -0300, Marcos Paulo de Souza
> > > wrote:
> > > > When running current selftests on older distributions like
> > > > SLE12-
> > > > SP5 that
> > > > contains an older bash trips over heredoc. Convert it to plain
> > > > echo
> > > > calls, which ends up with the same result.
> > > >
> > >
> > > Acked-by: Joe Lawrence <joe.lawrence@redhat.com>
> >
> > Thanks for the review Joe!
> >
> > >
> > > Just curious, what's the bash/heredoc issue? All I could find
> > > via
> > > google search was perhaps something to do with the temporary file
> > > implementation under the hood.
> >
> > # ./test-ftrace.sh
> > cat: -: No such file or directory
> > TEST: livepatch interaction with ftrace_enabled sysctl ... ^CQEMU:
> > Terminated
>
> I cannot reproduce it locally on SLE12-SP5. The patched test-
> ftrace.sh
> runs smoothly without 2/2.
>
> linux:~/linux/tools/testing/selftests/livepatch # ./test-ftrace.sh
> TEST: livepatch interaction with ftrace_enabled sysctl ... ok
> TEST: trace livepatched function and check that the live patch
> remains in effect ... ok
> TEST: livepatch a traced function and check that the live patch
> remains in effect ... ok
>
> GNU bash, version 4.3.48(1)-release (x86_64-suse-linux-gnu)
>
> Does "set -x" in the script give you anything interesting?
Nope:
boot_livepatch:/mnt/tools/testing/selftests/livepatch # ./test-trace.sh
+ cat
cat: -: No such file or directory
+ set_ftrace_enabled 1
+ local can_fail=0
Same version here:
GNU bash, version 4.3.48(1)-release (x86_64-suse-linux-gnu)
I'm using virtme-ng, so I'm not sure if this is related. At the same
time it works on SLE15-SP4, using the same virtme-ng, but with a
different bash:
GNU bash, version 4.4.23(1)-release (x86_64-suse-linux-gnu)
So I was blaming bash for this issue...
>
> Miroslav
^ permalink raw reply
* Re: [PATCH] kernel/trace/ftrace: introduce ftrace module notifier
From: Steven Rostedt @ 2026-02-26 17:30 UTC (permalink / raw)
To: Miroslav Benes
Cc: Song Chen, mcgrof, petr.pavlu, da.gomez, samitolvanen, atomlin,
mhiramat, mark.rutland, mathieu.desnoyers, linux-modules,
linux-kernel, linux-trace-kernel, live-patching
In-Reply-To: <alpine.LSU.2.21.2602261147150.5739@pobox.suse.cz>
On Thu, 26 Feb 2026 11:51:53 +0100 (CET)
Miroslav Benes <mbenes@suse.cz> wrote:
> > Let me see if there is any way to use notifier and remain below calling
> > sequence:
> >
> > ftrace_module_enable
> > klp_module_coming
> > blocking_notifier_call_chain_robust(MODULE_STATE_COMING)
> >
> > blocking_notifier_call_chain(MODULE_STATE_GOING)
> > klp_module_going
> > ftrace_release_mod
>
> Both klp and ftrace used module notifiers in the past. We abandoned that
> and opted for direct calls due to issues with ordering at the time. I do
> not have the list of problems at hand but I remember it was very fragile.
>
> See commits 7dcd182bec27 ("ftrace/module: remove ftrace module
> notifier"), 7e545d6eca20 ("livepatch/module: remove livepatch module
> notifier") and their surroundings.
>
> So unless there is a reason for the change (which should be then carefully
> reviewed and properly tested), I would prefer to keep it as is. What is
> the motivation? I am failing to find it in the commit log.
Honestly, I do think just decoupling ftrace and live kernel patching from
modules is rationale enough, as it makes the code a bit cleaner. But to do
so, we really need to make sure there is absolutely no regressions.
Thus, to allow such a change, I would ask those that are proposing it, show
a full work flow of how ftrace, live kernel patching, and modules work with
each other and why those functions are currently injected in the module code.
As Miroslav stated, we tried to do it via notifiers in the past and it
failed. I don't want to find out why they failed by just adding them back
to notifiers again. Instead, the reasons must be fully understood and
updates made to make sure they will not fail in the future.
-- Steve
^ permalink raw reply
* Re: [PATCH] kernel/trace/ftrace: introduce ftrace module notifier
From: Song Chen @ 2026-02-27 1:34 UTC (permalink / raw)
To: Steven Rostedt, Miroslav Benes
Cc: mcgrof, petr.pavlu, da.gomez, samitolvanen, atomlin, mhiramat,
mark.rutland, mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel, live-patching
In-Reply-To: <20260226123014.2197d9b7@gandalf.local.home>
Hi,
在 2026/2/27 01:30, Steven Rostedt 写道:
> On Thu, 26 Feb 2026 11:51:53 +0100 (CET)
> Miroslav Benes <mbenes@suse.cz> wrote:
>
>>> Let me see if there is any way to use notifier and remain below calling
>>> sequence:
>>>
>>> ftrace_module_enable
>>> klp_module_coming
>>> blocking_notifier_call_chain_robust(MODULE_STATE_COMING)
>>>
>>> blocking_notifier_call_chain(MODULE_STATE_GOING)
>>> klp_module_going
>>> ftrace_release_mod
>>
>> Both klp and ftrace used module notifiers in the past. We abandoned that
>> and opted for direct calls due to issues with ordering at the time. I do
>> not have the list of problems at hand but I remember it was very fragile.
>>
>> See commits 7dcd182bec27 ("ftrace/module: remove ftrace module
>> notifier"), 7e545d6eca20 ("livepatch/module: remove livepatch module
>> notifier") and their surroundings.
>>
>> So unless there is a reason for the change (which should be then carefully
>> reviewed and properly tested), I would prefer to keep it as is. What is
>> the motivation? I am failing to find it in the commit log.
There is no special motivation, i just read btf initialization in module
loading and found direct calls of ftrace and klp, i thought they were
just forgotten to use notifier and i even didn't search git log to
verify, sorry about that.
>
> Honestly, I do think just decoupling ftrace and live kernel patching from
> modules is rationale enough, as it makes the code a bit cleaner. But to do
> so, we really need to make sure there is absolutely no regressions.
>
> Thus, to allow such a change, I would ask those that are proposing it, show
> a full work flow of how ftrace, live kernel patching, and modules work with
> each other and why those functions are currently injected in the module code.
>
> As Miroslav stated, we tried to do it via notifiers in the past and it
> failed. I don't want to find out why they failed by just adding them back
> to notifiers again. Instead, the reasons must be fully understood and
> updates made to make sure they will not fail in the future.
Yes, you are right, i read commit msg of 7dcd182bec27, this patch just
reverses it simply and will introduce order issue back. I will try to
find out the problem in the past at first.
Thank you both.
/Song
>
> -- Steve
>
>
^ permalink raw reply
* Re: [PATCH v3 8/8] livepatch: Add tests for klp-build toolchain
From: Miroslav Benes @ 2026-02-27 10:04 UTC (permalink / raw)
To: Song Liu; +Cc: live-patching, jpoimboe, jikos, pmladek, joe.lawrence,
kernel-team
In-Reply-To: <20260226005436.379303-9-song@kernel.org>
Hi,
I have a couple of questions before reviewing the code itself. See below.
I removed the code completely as it seems better to have it compact. Sorry
if it is too confusing in the end and I apologize for being late to the
party. We can always merge the first 7 patches when they are settled and
keep this one separate.
On Wed, 25 Feb 2026, Song Liu wrote:
> Add selftests for the klp-build toolchain. This includes kernel side test
> code and .patch files. The tests cover both livepatch to vmlinux and kernel
> modules.
>
> Check tools/testing/selftests/livepatch/test_patches/README for
> instructions to run these tests.
>
> Signed-off-by: Song Liu <song@kernel.org>
>
> ---
>
> AI was used to wrote the test code and .patch files in this.
This should go to the changelog directly. See new
Documentation/process/generated-content.rst.
> ---
> kernel/livepatch/Kconfig | 20 +++
> kernel/livepatch/Makefile | 2 +
> kernel/livepatch/tests/Makefile | 6 +
> kernel/livepatch/tests/klp_test_module.c | 111 ++++++++++++++
> kernel/livepatch/tests/klp_test_module.h | 8 +
> kernel/livepatch/tests/klp_test_vmlinux.c | 138 ++++++++++++++++++
> kernel/livepatch/tests/klp_test_vmlinux.h | 16 ++
> kernel/livepatch/tests/klp_test_vmlinux_aux.c | 59 ++++++++
> .../selftests/livepatch/test_patches/README | 15 ++
> .../test_patches/klp_test_hash_change.patch | 30 ++++
> .../test_patches/klp_test_module.patch | 18 +++
> .../klp_test_nonstatic_to_static.patch | 40 +++++
> .../klp_test_static_to_nonstatic.patch | 39 +++++
> .../test_patches/klp_test_vmlinux.patch | 18 +++
> 14 files changed, 520 insertions(+)
> create mode 100644 kernel/livepatch/tests/Makefile
> create mode 100644 kernel/livepatch/tests/klp_test_module.c
> create mode 100644 kernel/livepatch/tests/klp_test_module.h
> create mode 100644 kernel/livepatch/tests/klp_test_vmlinux.c
> create mode 100644 kernel/livepatch/tests/klp_test_vmlinux.h
> create mode 100644 kernel/livepatch/tests/klp_test_vmlinux_aux.c
> create mode 100644 tools/testing/selftests/livepatch/test_patches/README
> create mode 100644 tools/testing/selftests/livepatch/test_patches/klp_test_hash_change.patch
> create mode 100644 tools/testing/selftests/livepatch/test_patches/klp_test_module.patch
> create mode 100644 tools/testing/selftests/livepatch/test_patches/klp_test_nonstatic_to_static.patch
> create mode 100644 tools/testing/selftests/livepatch/test_patches/klp_test_static_to_nonstatic.patch
> create mode 100644 tools/testing/selftests/livepatch/test_patches/klp_test_vmlinux.patch
We store test modules in tools/testing/selftests/livepatch/test_modules/
now. Could you move klp_test_module.c there, please? You might also reuse
existing ones for the purpose perhaps.
What about vmlinux? I understand that it provides a lot more flexibility
to have separate functions for testing but would it be somehow sufficient
to use the existing (real) kernel functions? Like cmdline_proc_show() and
such which we use everywhere else? Or would it be to limited? I am fine if
you find it necessary in the end. I just think that reusing as much as
possible is generally a good approach.
The patch mentiones kpatch in some places. Could you replace it, please?
And a little bit of bikeshedding at the end. I think it would be more
descriptive if the new config options and tests (test modules) have
klp-build somewhere in the name to keep it clear. What do you think?
Thanks for the patches!
Miroslav
^ permalink raw reply
* Re: [PATCH 2/2] selftests: livepatch: functions.sh: Workaround heredoc on older bash
From: Marcos Paulo de Souza @ 2026-02-27 14:28 UTC (permalink / raw)
To: Miroslav Benes
Cc: Joe Lawrence, Josh Poimboeuf, Jiri Kosina, Petr Mladek,
Shuah Khan, live-patching, linux-kselftest, linux-kernel
In-Reply-To: <3a4a2d27c241bda76a0b5cf812f7921088d5cbd8.camel@suse.com>
On Thu, 2026-02-26 at 11:34 -0300, Marcos Paulo de Souza wrote:
> On Thu, 2026-02-26 at 13:40 +0100, Miroslav Benes wrote:
> > Hi,
> >
> > On Mon, 23 Feb 2026, Marcos Paulo de Souza wrote:
> >
> > > On Mon, 2026-02-23 at 10:42 -0500, Joe Lawrence wrote:
> > > > On Fri, Feb 20, 2026 at 11:12:34AM -0300, Marcos Paulo de Souza
> > > > wrote:
> > > > > When running current selftests on older distributions like
> > > > > SLE12-
> > > > > SP5 that
> > > > > contains an older bash trips over heredoc. Convert it to
> > > > > plain
> > > > > echo
> > > > > calls, which ends up with the same result.
> > > > >
> > > >
> > > > Acked-by: Joe Lawrence <joe.lawrence@redhat.com>
> > >
> > > Thanks for the review Joe!
> > >
> > > >
> > > > Just curious, what's the bash/heredoc issue? All I could find
> > > > via
> > > > google search was perhaps something to do with the temporary
> > > > file
> > > > implementation under the hood.
> > >
> > > # ./test-ftrace.sh
> > > cat: -: No such file or directory
> > > TEST: livepatch interaction with ftrace_enabled sysctl ...
> > > ^CQEMU:
> > > Terminated
> >
> > I cannot reproduce it locally on SLE12-SP5. The patched test-
> > ftrace.sh
> > runs smoothly without 2/2.
> >
> > linux:~/linux/tools/testing/selftests/livepatch # ./test-ftrace.sh
> > TEST: livepatch interaction with ftrace_enabled sysctl ... ok
> > TEST: trace livepatched function and check that the live patch
> > remains in effect ... ok
> > TEST: livepatch a traced function and check that the live patch
> > remains in effect ... ok
> >
> > GNU bash, version 4.3.48(1)-release (x86_64-suse-linux-gnu)
> >
> > Does "set -x" in the script give you anything interesting?
>
> Nope:
>
> boot_livepatch:/mnt/tools/testing/selftests/livepatch # ./test-
> trace.sh
> + cat
> cat: -: No such file or directory
> + set_ftrace_enabled 1
> + local can_fail=0
>
>
> Same version here:
> GNU bash, version 4.3.48(1)-release (x86_64-suse-linux-gnu)
>
> I'm using virtme-ng, so I'm not sure if this is related. At the same
> time it works on SLE15-SP4, using the same virtme-ng, but with a
> different bash:
> GNU bash, version 4.4.23(1)-release (x86_64-suse-linux-gnu)
>
> So I was blaming bash for this issue...
This patch can be skipped. For the record, I discovered that it only
happens when vng is called using --rw, making it to fail on older bash
since it doesn't create overlays for /tmp. If the overlay is added the
issue is gone.
So, this patch can be skipped. Thanks Miroslav for testing!
>
> >
> > Miroslav
^ permalink raw reply
* Re: [PATCH v3 8/8] livepatch: Add tests for klp-build toolchain
From: Song Liu @ 2026-02-27 17:26 UTC (permalink / raw)
To: Miroslav Benes
Cc: live-patching, jpoimboe, jikos, pmladek, joe.lawrence,
kernel-team
In-Reply-To: <alpine.LSU.2.21.2602271052240.374@pobox.suse.cz>
Hi Miroslav,
On Fri, Feb 27, 2026 at 2:05 AM Miroslav Benes <mbenes@suse.cz> wrote:
>
> Hi,
>
> I have a couple of questions before reviewing the code itself. See below.
> I removed the code completely as it seems better to have it compact. Sorry
> if it is too confusing in the end and I apologize for being late to the
> party. We can always merge the first 7 patches when they are settled and
> keep this one separate.
Yes, I was also thinking this patch will need more discussions than the
rest of the set.
> On Wed, 25 Feb 2026, Song Liu wrote:
>
> > Add selftests for the klp-build toolchain. This includes kernel side test
> > code and .patch files. The tests cover both livepatch to vmlinux and kernel
> > modules.
> >
> > Check tools/testing/selftests/livepatch/test_patches/README for
> > instructions to run these tests.
> >
> > Signed-off-by: Song Liu <song@kernel.org>
> >
> > ---
> >
> > AI was used to wrote the test code and .patch files in this.
>
> This should go to the changelog directly. See new
> Documentation/process/generated-content.rst.
Thanks for pointing this out. I didn't know we had this guidance.
>
> > ---
> > kernel/livepatch/Kconfig | 20 +++
> > kernel/livepatch/Makefile | 2 +
> > kernel/livepatch/tests/Makefile | 6 +
> > kernel/livepatch/tests/klp_test_module.c | 111 ++++++++++++++
> > kernel/livepatch/tests/klp_test_module.h | 8 +
> > kernel/livepatch/tests/klp_test_vmlinux.c | 138 ++++++++++++++++++
> > kernel/livepatch/tests/klp_test_vmlinux.h | 16 ++
> > kernel/livepatch/tests/klp_test_vmlinux_aux.c | 59 ++++++++
> > .../selftests/livepatch/test_patches/README | 15 ++
> > .../test_patches/klp_test_hash_change.patch | 30 ++++
> > .../test_patches/klp_test_module.patch | 18 +++
> > .../klp_test_nonstatic_to_static.patch | 40 +++++
> > .../klp_test_static_to_nonstatic.patch | 39 +++++
> > .../test_patches/klp_test_vmlinux.patch | 18 +++
> > 14 files changed, 520 insertions(+)
> > create mode 100644 kernel/livepatch/tests/Makefile
> > create mode 100644 kernel/livepatch/tests/klp_test_module.c
> > create mode 100644 kernel/livepatch/tests/klp_test_module.h
> > create mode 100644 kernel/livepatch/tests/klp_test_vmlinux.c
> > create mode 100644 kernel/livepatch/tests/klp_test_vmlinux.h
> > create mode 100644 kernel/livepatch/tests/klp_test_vmlinux_aux.c
> > create mode 100644 tools/testing/selftests/livepatch/test_patches/README
> > create mode 100644 tools/testing/selftests/livepatch/test_patches/klp_test_hash_change.patch
> > create mode 100644 tools/testing/selftests/livepatch/test_patches/klp_test_module.patch
> > create mode 100644 tools/testing/selftests/livepatch/test_patches/klp_test_nonstatic_to_static.patch
> > create mode 100644 tools/testing/selftests/livepatch/test_patches/klp_test_static_to_nonstatic.patch
> > create mode 100644 tools/testing/selftests/livepatch/test_patches/klp_test_vmlinux.patch
>
> We store test modules in tools/testing/selftests/livepatch/test_modules/
> now. Could you move klp_test_module.c there, please? You might also reuse
> existing ones for the purpose perhaps.
IIUC, tools/testing/selftests/livepatch/test_modules/ is more like an out
of tree module. In the case of testing klp-build, we prefer to have it to
work the same as in-tree modules. This is important because klp-build
is a toolchain, and any changes of in-tree Makefiles may cause issues
with klp-build. Current version can catch these issues easily. If we build
the test module as an OOT module, we may miss some of these issues.
In the longer term, we should consider adding klp-build support to build
livepatch for OOT modules. But for now, good test coverage for in-tree
modules are more important.
>
> What about vmlinux? I understand that it provides a lot more flexibility
> to have separate functions for testing but would it be somehow sufficient
> to use the existing (real) kernel functions? Like cmdline_proc_show() and
> such which we use everywhere else? Or would it be to limited? I am fine if
> you find it necessary in the end. I just think that reusing as much as
> possible is generally a good approach.
I think using existing functions would be too limited, and Joe seems to
agree with this based on his experience. To be able to test corner cases
of the compiler/linker, such as LTO, we need special code patterns.
OTOH, if we want to use an existing kernel function for testing, it needs
to be relatively stable, i.e., not being changed very often. It is not always
easy to find some known to be stable code that follows specific patterns.
If we add dedicated code as test targets, things will be much easier
down the road.
CC Joe to chime in here.
>
> The patch mentiones kpatch in some places. Could you replace it, please?
I was using kpatch for testing. I can replace it with insmod.
> And a little bit of bikeshedding at the end. I think it would be more
> descriptive if the new config options and tests (test modules) have
> klp-build somewhere in the name to keep it clear. What do you think?
Technically, we can also use these tests to test other toolchains, for
example, kpatch-build. I don't know ksplice or kGraft enough to tell
whether they can benefit from these tests or not. OTOH, I am OK
changing the name/description of these config options.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH v3 8/8] livepatch: Add tests for klp-build toolchain
From: Miroslav Benes @ 2026-03-02 8:38 UTC (permalink / raw)
To: Song Liu; +Cc: live-patching, jpoimboe, jikos, pmladek, joe.lawrence,
kernel-team
In-Reply-To: <CAPhsuW69EZTcMGyXSKv2fEjh7mhtYaSxriZrSgX0nTPCEYKS7A@mail.gmail.com>
Him
> > We store test modules in tools/testing/selftests/livepatch/test_modules/
> > now. Could you move klp_test_module.c there, please? You might also reuse
> > existing ones for the purpose perhaps.
>
> IIUC, tools/testing/selftests/livepatch/test_modules/ is more like an out
> of tree module. In the case of testing klp-build, we prefer to have it to
> work the same as in-tree modules. This is important because klp-build
> is a toolchain, and any changes of in-tree Makefiles may cause issues
> with klp-build. Current version can catch these issues easily. If we build
> the test module as an OOT module, we may miss some of these issues.
> In the longer term, we should consider adding klp-build support to build
> livepatch for OOT modules. But for now, good test coverage for in-tree
> modules are more important.
Ok. I thought it would not matter but it is a fair point.
> > What about vmlinux? I understand that it provides a lot more flexibility
> > to have separate functions for testing but would it be somehow sufficient
> > to use the existing (real) kernel functions? Like cmdline_proc_show() and
> > such which we use everywhere else? Or would it be to limited? I am fine if
> > you find it necessary in the end. I just think that reusing as much as
> > possible is generally a good approach.
>
> I think using existing functions would be too limited, and Joe seems to
> agree with this based on his experience. To be able to test corner cases
> of the compiler/linker, such as LTO, we need special code patterns.
> OTOH, if we want to use an existing kernel function for testing, it needs
> to be relatively stable, i.e., not being changed very often. It is not always
> easy to find some known to be stable code that follows specific patterns.
> If we add dedicated code as test targets, things will be much easier
> down the road.
Fair enough.
> > And a little bit of bikeshedding at the end. I think it would be more
> > descriptive if the new config options and tests (test modules) have
> > klp-build somewhere in the name to keep it clear. What do you think?
>
> Technically, we can also use these tests to test other toolchains, for
> example, kpatch-build. I don't know ksplice or kGraft enough to tell
> whether they can benefit from these tests or not. OTOH, I am OK
> changing the name/description of these config options.
I would prefer it, thank you. Unless someone else objects of course.
Regards,
Miroslav
^ permalink raw reply
* Re: [PATCH v3 09/13] livepatch/klp-build: fix version mismatch when short-circuiting
From: Joe Lawrence @ 2026-03-03 2:20 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: live-patching, Song Liu, Jiri Kosina, Miroslav Benes, Petr Mladek
In-Reply-To: <zyxlceita2k3szzck5fwhhnpinh3twtzpr23xkdxdpj4opkgog@dnsvvttl4r3x>
On Mon, Feb 23, 2026 at 01:13:29PM -0800, Josh Poimboeuf wrote:
> On Tue, Feb 17, 2026 at 11:17:00AM -0500, Joe Lawrence wrote:
> > Maybe I'm starting to see things, but when running 'S 2' builds, I keep
> > getting "vmlinux.o: changed function: override_release". It could be
> > considered benign for quick development work, or confusing. Seems easy
> > enough to stash and avoid.
> >
> > Repro:
> >
> > Start with a clean source tree, setup some basic configs for klp-build:
> >
> > $ make clean && make mrproper
> > $ vng --kconfig
> > $ ./scripts/config --file .config \
> > --set-val CONFIG_FTRACE y \
> > --set-val CONFIG_KALLSYMS_ALL y \
> > --set-val CONFIG_FUNCTION_TRACER y \
> > --set-val CONFIG_DYNAMIC_FTRACE y \
> > --set-val CONFIG_DYNAMIC_DEBUG y \
> > --set-val CONFIG_LIVEPATCH y
> > $ make olddefconfig
> >
> > Build the first patch, save klp-tmp/ (note the added DEBUG that dumps
> > the localversion after assignment in set_kernelversion):
> >
> > $ ./scripts/livepatch/klp-build -T ~/cmdline-string.patch
> > DEBUG: localversion=6.19.0-gc998cd490c02 <<
> > Validating patch(es)
> > Building original kernel
> > Copying original object files
> > Fixing patch(es)
> > Building patched kernel
> > Copying patched object files
> > Diffing objects
> > vmlinux.o: changed function: cmdline_proc_show
> > BMuilding patch module: livepatch-cmdline-string.ko
> > SgUCCESS
> > c
> > Buield a second patch, short-circuit to step 2 (build patched kernel):
> >
> > $ ./scripts/livepatch/klp-build -T -S 2 ~/cmdline-string.patch
> > DEBUG: localversion=6.19.0+ <<
> > Fixing patch(es)
> > Building patched kernel
> > Copying patched object files
> > Diffing objects
> > vmlinux.o: changed function: override_release <<
> > vmlinux.o: changed function: cmdline_proc_show
> > Building patch module: livepatch-cmdline-string.ko
> > SUCCESS
>
> Hm, I wasn't able to recreate, but it's worrisome that two different
> localversions are being reported. How do we know which one is correct?
>
> I'm also not sure why my original code is being so obtuse by
> constructing the kernelrelease manually. I can't remember if that's on
> purpose or not.
>
> The below would be simpler, I wonder if this also happens to fix the
> issue?
>
I finally figured out why you couldn't reproduce, in my tests, I never
built the original kernel, I jumped straight from a clean repo to
starting up klp-build. If I perform an initial make before running
klp-build, then the sequence works as expected.
- If skipping the initial vmlinux is an unsupported use-case, then we
can ignore and drop this patch,
- or perhaps detect and warn/error out
- If this is something we need to support, then your suggested version
below didn't work out either...
The following change committed on top of v7.0-rc2:
diff --git a/scripts/livepatch/klp-build b/scripts/livepatch/klp-build
index 809e198a561d..f223395e630e 100755
--- a/scripts/livepatch/klp-build
+++ b/scripts/livepatch/klp-build
@@ -285,15 +285,16 @@ set_module_name() {
# application from appending it with '+' due to a dirty git working tree.
set_kernelversion() {
local file="$SRC/scripts/setlocalversion"
- local localversion
+ local kernelrelease
stash_file "$file"
- localversion="$(cd "$SRC" && make --no-print-directory kernelversion)"
- localversion="$(cd "$SRC" && KERNELVERSION="$localversion" ./scripts/setlocalversion)"
- [[ -z "$localversion" ]] && die "setlocalversion failed"
+ kernelrelease="$(cd "$SRC" && make kernelrelease)"
+ [[ -z "$kernelrelease" ]] && die "setlocalversion failed"
- sed -i "2i echo $localversion; exit 0" scripts/setlocalversion
+ echo "DEBUG: kernelrelease=$kernelrelease"
+
+ sed -i "2i echo $kernelrelease; exit 0" scripts/setlocalversion
}
get_patch_files() {
$ git clone --branch v7.0-rc2 --depth=1 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[ add the commit above ]
$ git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
nothing to commit, working tree clean
$ vng --kconfig
$ ./scripts/config --file .config \
--set-val CONFIG_FTRACE y \
--set-val CONFIG_KALLSYMS_ALL y \
--set-val CONFIG_FUNCTION_TRACER y \
--set-val CONFIG_DYNAMIC_FTRACE y \
--set-val CONFIG_DYNAMIC_DEBUG y \
--set-val CONFIG_LIVEPATCH y
$ make olddefconfig
$ ./scripts/livepatch/klp-build -T ~/src/linux/cmdline-string.patch
DEBUG: kernelrelease=7.0.0-rc2-00001-g624702e6338b
Validating patch(es)
Building original kernel
Copying original object files
Fixing patch(es)
Building patched kernel
Copying patched object files
Diffing objects
vmlinux.o: changed function: cmdline_proc_show
Building patch module: livepatch-cmdline-string.ko
SUCCESS
$ strings livepatch-cmdline-string.ko | grep vermagic
vermagic=7.0.0-rc2-00001-g624702e6338b SMP preempt mod_unload
$ ./scripts/livepatch/klp-build -T -S 2 ~/src/linux/cmdline-string.patch
DEBUG: kernelrelease=7.0.0-rc2+
Fixing patch(es)
Building patched kernel
Copying patched object files
Diffing objects
vmlinux.o: changed function: override_release
vmlinux.o: changed function: cmdline_proc_show
Building patch module: livepatch-cmdline-string.ko
SUCCESS
$ strings livepatch-cmdline-string.ko | grep vermagic
vermagic=7.0.0-rc2+ SMP preempt mod_unload
--
Joe
^ permalink raw reply related
* Re: [PATCH v3 10/13] livepatch/klp-build: provide friendlier error messages
From: Joe Lawrence @ 2026-03-03 2:20 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: live-patching, Song Liu, Jiri Kosina, Miroslav Benes, Petr Mladek
In-Reply-To: <g27qxnginju67wz2eqhfy4mnaerydaw5mh3tbtlb5zo5pj5unu@th5y2kq7xokf>
On Mon, Feb 23, 2026 at 01:15:55PM -0800, Josh Poimboeuf wrote:
> On Tue, Feb 17, 2026 at 11:06:41AM -0500, Joe Lawrence wrote:
> > Provide more context for common klp-build failure modes. Clarify which
> > user-provided patch is unsupported or failed to apply, and explicitly
> > identify which kernel build (original or patched) failed.
> >
> > Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
> > ---
> > scripts/livepatch/klp-build | 9 +++++----
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/scripts/livepatch/klp-build b/scripts/livepatch/klp-build
> > index 6d3adadfc394..80703ec4d775 100755
> > --- a/scripts/livepatch/klp-build
> > +++ b/scripts/livepatch/klp-build
> > @@ -351,7 +351,7 @@ check_unsupported_patches() {
> > for file in "${files[@]}"; do
> > case "$file" in
> > lib/*|*.S)
> > - die "unsupported patch to $file"
> > + die "$patch unsupported patch to $file"
>
> Can we add a colon here, like
>
> foo.patch: unsupported patch to bar.c
>
Good idea, will do in v4.
--
Joe
^ permalink raw reply
* Re: [PATCH v3 11/13] livepatch/klp-build: add terminal color output
From: Joe Lawrence @ 2026-03-03 2:24 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: live-patching, Song Liu, Jiri Kosina, Miroslav Benes, Petr Mladek
In-Reply-To: <oetssfso7zbcsleiapmqwfiwqcobu3ghsf26ubxbqnkild7dve@hpa3e45rgtp7>
On Mon, Feb 23, 2026 at 01:32:09PM -0800, Josh Poimboeuf wrote:
> On Mon, Feb 23, 2026 at 01:28:45PM -0800, Josh Poimboeuf wrote:
> > On Tue, Feb 17, 2026 at 11:06:42AM -0500, Joe Lawrence wrote:
> > > Improve the readability of klp-build output by implementing a basic
> > > color scheme. When the standard output and error are connected to a
> > > terminal, highlight status messages in bold, warnings in yellow, and
> > > errors in red.
> > >
> > > Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
> > > ---
> > > scripts/livepatch/klp-build | 15 ++++++++++++---
> > > 1 file changed, 12 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/scripts/livepatch/klp-build b/scripts/livepatch/klp-build
> > > index 80703ec4d775..fd104ace29e6 100755
> > > --- a/scripts/livepatch/klp-build
> > > +++ b/scripts/livepatch/klp-build
> > > @@ -52,6 +52,15 @@ PATCH_TMP_DIR="$TMP_DIR/tmp"
> > >
> > > KLP_DIFF_LOG="$DIFF_DIR/diff.log"
> > >
> > > +# Terminal output colors
> > > +read -r COLOR_RESET COLOR_BOLD COLOR_ERROR COLOR_WARN <<< ""
> > > +if [[ -t 1 && -t 2 ]]; then
> > > + COLOR_RESET="\033[0m"
> > > + COLOR_BOLD="\033[1m"
> > > + COLOR_ERROR="\033[0;31m"
> > > + COLOR_WARN="\033[0;33m"
> > > +fi
> > > +
> > > grep0() {
> > > # shellcheck disable=SC2317
> > > command grep "$@" || true
> > > @@ -65,15 +74,15 @@ grep() {
> > > }
> > >
> > > status() {
> > > - echo "$*"
> > > + echo -e "${COLOR_BOLD}$*${COLOR_RESET}"
> > > }
> > >
> > > warn() {
> > > - echo "error: $SCRIPT: $*" >&2
> > > + echo -e "${COLOR_WARN}warn${COLOR_RESET}: $SCRIPT: $*" >&2
> >
> > Shouldn't this reset the colors *after* printing out the whole message?
> >
Colorizing the "warn:" and "error:" was intended to look similar to gcc
color output. I can easily highlight the entire message if you prefer.
> > Also, while it does make sense for warn() to print "warn:" rather than
> > "error:", note its called by trap_err(), which should print the latter.
>
> also I think s/warn:/warning:/ is better.
>
Ack to both for v4.
--
Joe
^ permalink raw reply
* Re: [PATCH v3 12/13] livepatch/klp-build: report patch validation drift
From: Joe Lawrence @ 2026-03-03 2:27 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: live-patching, Song Liu, Jiri Kosina, Miroslav Benes, Petr Mladek
In-Reply-To: <7iqwondhaweraszxu2xyjbz7lq6ttdd3yvg3erzuurboo757ov@4b5h7apjdarm>
On Mon, Feb 23, 2026 at 01:40:14PM -0800, Josh Poimboeuf wrote:
> On Tue, Feb 17, 2026 at 11:06:43AM -0500, Joe Lawrence wrote:
> > Capture the output of the patch command to detect when a patch applies
> > with fuzz or line offsets.
> >
> > If such "drift" is detected during the validation phase, warn the user
> > and display the details. This helps identify input patches that may need
> > refreshing against the target source tree.
> >
> > Ensure that internal patch operations (such as those in refresh_patch or
> > during the final build phase) can still run quietly.
> >
> > Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
> > ---
> > scripts/livepatch/klp-build | 24 +++++++++++++++++++-----
> > 1 file changed, 19 insertions(+), 5 deletions(-)
> >
> > diff --git a/scripts/livepatch/klp-build b/scripts/livepatch/klp-build
> > index fd104ace29e6..5367d573b94b 100755
> > --- a/scripts/livepatch/klp-build
> > +++ b/scripts/livepatch/klp-build
> > @@ -369,11 +369,24 @@ check_unsupported_patches() {
> >
> > apply_patch() {
> > local patch="$1"
> > + shift
> > + local extra_args=("$@")
> > + local drift_regex="with fuzz|offset [0-9]+ line"
> > + local output
> > + local status
> >
> > [[ ! -f "$patch" ]] && die "$patch doesn't exist"
> > - patch -d "$SRC" -p1 --dry-run --silent --no-backup-if-mismatch -r /dev/null < "$patch"
> > - patch -d "$SRC" -p1 --silent --no-backup-if-mismatch -r /dev/null < "$patch"
> > + status=0
> > + output=$(patch -d "$SRC" -p1 --dry-run --no-backup-if-mismatch -r /dev/null "${extra_args[@]}" < "$patch" 2>&1) || status=$?
> > + if [[ "$status" -ne 0 ]]; then
> > + echo "$output"
> > + die "$patch did not apply"
> > + elif [[ "$output" =~ $drift_regex ]]; then
> > + warn "$patch applied with drift"
> > + echo "$output"
>
> Just for consistency with the output ordering of the "patch did not
> apply" error, I think the "$output" should be printed *before* the
> "$patch applied with drift".
>
> Also, should $output be printed to stderr?
>
Will adjust both ^^ for v4.
> Also, I've not heard of patch "drift", is "fuzz" better?
>
Ah, I was trying to figure what word would include both offset and fuzz.
I /think/ "fuzz" may be used for both, so I can just use that for v4.
--
Joe
^ permalink raw reply
* Re: [PATCH v3 13/13] livepatch/klp-build: don't look for changed objects in tools/
From: Joe Lawrence @ 2026-03-03 2:30 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: live-patching, Song Liu, Jiri Kosina, Miroslav Benes, Petr Mladek
In-Reply-To: <os3ykxdsfe6bz2b2pd5x5wb76ya5ecogbvjgkcophf55wchv7r@vdp2dzrzrdny>
On Mon, Feb 23, 2026 at 01:41:58PM -0800, Josh Poimboeuf wrote:
> On Tue, Feb 17, 2026 at 11:06:44AM -0500, Joe Lawrence wrote:
> > Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
> > ---
> > scripts/livepatch/klp-build | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Why?
>
I don't have a pithy repro captured here, so I can just drop this for
now. I was playing with building klp-build selftest modules and
stashing the resulting .ko's under tools/testing/selftests.
Occasionally subsequent klp-builds would get confused when seeing only a
.ko and complaint about missing ancestor object files. Which led me to
ask, why does it look in directories that don't even include kernel
build artifacts.
--
Joe
^ permalink raw reply
* Re: [PATCH v3 8/8] livepatch: Add tests for klp-build toolchain
From: Joe Lawrence @ 2026-03-04 19:33 UTC (permalink / raw)
To: Miroslav Benes
Cc: Song Liu, live-patching, jpoimboe, jikos, pmladek, kernel-team
In-Reply-To: <alpine.LSU.2.21.2603020930540.21479@pobox.suse.cz>
On Mon, Mar 02, 2026 at 09:38:17AM +0100, Miroslav Benes wrote:
> Him
>
> > > We store test modules in tools/testing/selftests/livepatch/test_modules/
> > > now. Could you move klp_test_module.c there, please? You might also reuse
> > > existing ones for the purpose perhaps.
> >
> > IIUC, tools/testing/selftests/livepatch/test_modules/ is more like an out
> > of tree module. In the case of testing klp-build, we prefer to have it to
> > work the same as in-tree modules. This is important because klp-build
> > is a toolchain, and any changes of in-tree Makefiles may cause issues
> > with klp-build. Current version can catch these issues easily. If we build
> > the test module as an OOT module, we may miss some of these issues.
> > In the longer term, we should consider adding klp-build support to build
> > livepatch for OOT modules. But for now, good test coverage for in-tree
> > modules are more important.
>
> Ok. I thought it would not matter but it is a fair point.
>
> > > What about vmlinux? I understand that it provides a lot more flexibility
> > > to have separate functions for testing but would it be somehow sufficient
> > > to use the existing (real) kernel functions? Like cmdline_proc_show() and
> > > such which we use everywhere else? Or would it be to limited? I am fine if
> > > you find it necessary in the end. I just think that reusing as much as
> > > possible is generally a good approach.
> >
> > I think using existing functions would be too limited, and Joe seems to
> > agree with this based on his experience. To be able to test corner cases
> > of the compiler/linker, such as LTO, we need special code patterns.
> > OTOH, if we want to use an existing kernel function for testing, it needs
> > to be relatively stable, i.e., not being changed very often. It is not always
> > easy to find some known to be stable code that follows specific patterns.
> > If we add dedicated code as test targets, things will be much easier
> > down the road.
>
> Fair enough.
>
I've been tinkering with ideas in this space, though I took it in a very
different direction.
(First a disclaimer, this effort is largely the result of vibe coding
with Claude to prototype testing concepts, so I don't believe any of it
is reliable or upstream-worthy at this point.)
From a top-down perspective, I might start with the generated test
reports:
- https://file.rdu.redhat.com/~jolawren/artifacts/report.html
- https://file.rdu.redhat.com/~jolawren/artifacts/report.txt
and then in my own words:
1- I'm interested in testing several kernel configurations (distros,
debug, thinLTO) as well as toolchains (gcc, llvm) against the same
source tree and machine. I call these config/toolchain pairs a testing
"profile". In the report examples, these are combos like "fedora-43 +
virtme-ng" and "virtme-ng + thin-lto".
2- For test cases, a few possible results:
PASS - should build / load / run
e.g. cmdline-string.patch
FAIL* - unexpected failure to build / load / run
e.g. some new bug in klp-build
XFAIL - expected to build / load / run failure
e.g. "no changed detected" patch
XPASS* - unexpected build / load / run success
e.g. "no changed detected" patch actually created a .ko
* These would be considered interesting to look at. Did we find a new
bug, or maybe an existing bug is now fixed?
3- Test cases and makefile target workflows are split into build and
runtime parts.
4- Based on kpatch-build experience, test cases are further divided into
"quick" and "long" sets with the understanding that klp-build testing
takes a non-trivial amount of time.
5- Two patch targets:
a) current-tree - target the user's current source tree
b) patched-tree - (temporarily) patch the user's tree to *exactly* what
we need to target
Why? In the kpatch-build project, patching the current-tree meant we
had to rebase patches for every release. We also had to hunt and find
precise scenarios across the kernel tree to test, hoping they wouldn't
go away in future versions. In other cases, the kernel or compiler
changed and we weren't testing the original problem any longer.
That said, patching a dummy patched-tree isn't be perfect either,
particularly in the runtime sense. You're not testing a release kernel,
but something slightly different.
(Tangent: kpatch-build implemented a unit test scheme that cached object
files for even greater speed and fixed testing. I haven't thought about
how a similar idea might work for klp-build.)
6- Two patch models:
a) static .patch files
b) scripted .patch generation
Why? Sometimes a test like cmdline-string.patch is sufficient and
stable. Other times it's not. For example, the recount-many-file test
in this branch is implemented via a script. This allows the test to be
dynamic and potentially avoid the rebasing problem mentioned above.
7- Build verification including ELF analysis. Not very mature in this
branch, but it would be nice to be able to build on it:
======================================================================
BUILD VERIFICATION
======================================================================
klp-build exit code is 0
Module exists: livepatch-cmdline-string.ko
verify_diff_log_contains('changed function: cmdline_proc_show'): OK
ELF Analysis:
klp_object[0]:
.name = NULL (vmlinux)
VERIFIED: klp_object.name = NULL (vmlinux)
klp_func[0]:
.old_name = "cmdline_proc_show" [-> .rodata+0x15d]
.new_func -> cmdline_proc_show
.old_sympos = 0
VERIFIED: klp_func.old_name = 'cmdline_proc_show'
VERIFIED: klp_func.new_func -> cmdline_proc_show
Perhaps even extending this to the intermediate klp-tmp/ files? This
would aid in greater sanity checking of what's produced, but also in
verifying that our test is still testing what it originally set out to.
(i.e. Is the thinLTO suffix test still generating two common symbols
with a different hash suffix?)
8- Probably more I've already forgotten about :) Cross-compilation may
be interesting for build testing in the future. For the full AI created
commentary, there's https://github.com/joe-lawrence/linux/blob/klp-build-selftests/README.md
> > I was using kpatch for testing. I can replace it with insmod.
>
Do the helpers in functions.sh for safely loading and unloading
livepatches (that wait for the transition, etc.) aid here?
> > > And a little bit of bikeshedding at the end. I think it would be more
> > > descriptive if the new config options and tests (test modules) have
> > > klp-build somewhere in the name to keep it clear. What do you think?
> >
> > Technically, we can also use these tests to test other toolchains, for
> > example, kpatch-build. I don't know ksplice or kGraft enough to tell
> > whether they can benefit from these tests or not. OTOH, I am OK
> > changing the name/description of these config options.
>
> I would prefer it, thank you. Unless someone else objects of course.
>
To continue the bike shedding, in my branch, I had dumped this all under
a new tools/testing/klp-build subdirectory as my focus was to put
klp-build through the paces. It does load the generated livepatches in
the runtime testing, but as only as a sanity check. With that, it
didn't touch CONFIG or intermix testing with the livepatch/ set.
If we do end up supplementing the livepatch/ with klp-build tests, then
I agree that naming them (either filename prefix or subdirectory) would
be nice.
But first, is it goal for klp-build to be the build tool (rather than
simple module kbuild) for the livepatching .ko selftests?
--
Joe
^ permalink raw reply
* Re: [PATCH v3 8/8] livepatch: Add tests for klp-build toolchain
From: Song Liu @ 2026-03-04 23:12 UTC (permalink / raw)
To: Joe Lawrence
Cc: Miroslav Benes, live-patching, jpoimboe, jikos, pmladek,
kernel-team
In-Reply-To: <aaiI7zv2JVgXZkPm@redhat.com>
On Wed, Mar 4, 2026 at 11:33 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
[...]
> I've been tinkering with ideas in this space, though I took it in a very
> different direction.
>
> (First a disclaimer, this effort is largely the result of vibe coding
> with Claude to prototype testing concepts, so I don't believe any of it
> is reliable or upstream-worthy at this point.)
>
> From a top-down perspective, I might start with the generated test
> reports:
>
> - https://file.rdu.redhat.com/~jolawren/artifacts/report.html
> - https://file.rdu.redhat.com/~jolawren/artifacts/report.txt
I cannot access these two links.
> and then in my own words:
>
[...]
>
> 5- Two patch targets:
>
> a) current-tree - target the user's current source tree
> b) patched-tree - (temporarily) patch the user's tree to *exactly* what
> we need to target
>
> Why? In the kpatch-build project, patching the current-tree meant we
> had to rebase patches for every release. We also had to hunt and find
> precise scenarios across the kernel tree to test, hoping they wouldn't
> go away in future versions. In other cases, the kernel or compiler
> changed and we weren't testing the original problem any longer.
I would prefer making patched-tree as upstream + some different
CONFIG_s. Otherwise, we will need to carry .patch files for the
patched-tree in selftests, which seems weird.
> That said, patching a dummy patched-tree isn't be perfect either,
> particularly in the runtime sense. You're not testing a release kernel,
> but something slightly different.
This should not be a problem. The goal is to test the klp-build toolchain.
> (Tangent: kpatch-build implemented a unit test scheme that cached object
> files for even greater speed and fixed testing. I haven't thought about
> how a similar idea might work for klp-build.)
I think it is a good idea to have similar .o file tests for klp-diff
in klp-build.
>
> 6- Two patch models:
>
> a) static .patch files
> b) scripted .patch generation
>
> Why? Sometimes a test like cmdline-string.patch is sufficient and
> stable. Other times it's not. For example, the recount-many-file test
> in this branch is implemented via a script. This allows the test to be
> dynamic and potentially avoid the rebasing problem mentioned above.
I think we can have both a) and b).
> 7- Build verification including ELF analysis. Not very mature in this
> branch, but it would be nice to be able to build on it:
If we test the behavior after loading the patches, ELF analysis might
be optional. But we can also do both.
[...]
>
> 8- Probably more I've already forgotten about :) Cross-compilation may
> be interesting for build testing in the future. For the full AI created
> commentary, there's https://github.com/joe-lawrence/linux/blob/klp-build-selftests/README.md
Yes, cross-compilation can be really useful.
> > > I was using kpatch for testing. I can replace it with insmod.
> >
>
> Do the helpers in functions.sh for safely loading and unloading
> livepatches (that wait for the transition, etc.) aid here?
Yes, we can reuse those.
[...]
> To continue the bike shedding, in my branch, I had dumped this all under
> a new tools/testing/klp-build subdirectory as my focus was to put
> klp-build through the paces. It does load the generated livepatches in
> the runtime testing, but as only as a sanity check. With that, it
> didn't touch CONFIG or intermix testing with the livepatch/ set.
>
> If we do end up supplementing the livepatch/ with klp-build tests, then
> I agree that naming them (either filename prefix or subdirectory) would
> be nice.
>
> But first, is it goal for klp-build to be the build tool (rather than
> simple module kbuild) for the livepatching .ko selftests?
I think we don't have to use klp-build for livepatch selftests. Existing
tests work well as-is.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH v3 8/8] livepatch: Add tests for klp-build toolchain
From: Joe Lawrence @ 2026-03-05 1:39 UTC (permalink / raw)
To: Song Liu
Cc: Miroslav Benes, live-patching, jpoimboe, jikos, pmladek,
kernel-team
In-Reply-To: <CAPhsuW6Nx6meWVCkTJXmp5BzTX_2s2dt1j+C-=AtMzQ8ZV396A@mail.gmail.com>
On Wed, Mar 04, 2026 at 03:12:48PM -0800, Song Liu wrote:
> On Wed, Mar 4, 2026 at 11:33 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
> [...]
>
> > I've been tinkering with ideas in this space, though I took it in a very
> > different direction.
> >
> > (First a disclaimer, this effort is largely the result of vibe coding
> > with Claude to prototype testing concepts, so I don't believe any of it
> > is reliable or upstream-worthy at this point.)
> >
> > From a top-down perspective, I might start with the generated test
> > reports:
> >
> > - https://file.rdu.redhat.com/~jolawren/artifacts/report.html
> > - https://file.rdu.redhat.com/~jolawren/artifacts/report.txt
>
> I cannot access these two links.
>
Gah, sorry about those internal links.
Try:
https://joe-lawrence.github.io/klp-build-selftest-artifacts/report.html
https://joe-lawrence.github.io/klp-build-selftest-artifacts/report.txt
> > and then in my own words:
> >
> [...]
> >
> > 5- Two patch targets:
> >
> > a) current-tree - target the user's current source tree
> > b) patched-tree - (temporarily) patch the user's tree to *exactly* what
> > we need to target
> >
> > Why? In the kpatch-build project, patching the current-tree meant we
> > had to rebase patches for every release. We also had to hunt and find
> > precise scenarios across the kernel tree to test, hoping they wouldn't
> > go away in future versions. In other cases, the kernel or compiler
> > changed and we weren't testing the original problem any longer.
>
> I would prefer making patched-tree as upstream + some different
> CONFIG_s. Otherwise, we will need to carry .patch files for the
> patched-tree in selftests, which seems weird.
>
It is strange, but for my experiment, I wanted minimal disruption to the
tree. For the "real" changeset, upstream + some testing CONFIG_ sounds
good to me.
> > That said, patching a dummy patched-tree isn't be perfect either,
> > particularly in the runtime sense. You're not testing a release kernel,
> > but something slightly different.
>
> This should not be a problem. The goal is to test the klp-build toolchain.
>
Right, perhaps klp-build testing always targets a slightly modified
kernel (or at least CONFIG_) while livepatching testing operates against
the stock tree?
> > (Tangent: kpatch-build implemented a unit test scheme that cached object
> > files for even greater speed and fixed testing. I haven't thought about
> > how a similar idea might work for klp-build.)
>
> I think it is a good idea to have similar .o file tests for klp-diff
> in klp-build.
>
kpatch-build uses a git submodule (a joy to work with /s), but maybe
upstream tree can fetch the binary objects from some external
(github/etc.) source? I wonder if there is any kselftest precident for
this, we'll need to investigate that.
> >
> > 6- Two patch models:
> >
> > a) static .patch files
> > b) scripted .patch generation
> >
> > Why? Sometimes a test like cmdline-string.patch is sufficient and
> > stable. Other times it's not. For example, the recount-many-file test
> > in this branch is implemented via a script. This allows the test to be
> > dynamic and potentially avoid the rebasing problem mentioned above.
>
> I think we can have both a) and b).
>
> > 7- Build verification including ELF analysis. Not very mature in this
> > branch, but it would be nice to be able to build on it:
>
> If we test the behavior after loading the patches, ELF analysis might
> be optional. But we can also do both.
>
Maybe, though doing so during the build test would give us that analysis
for future cross-compiled test cases without having to actually boot and
load them somewhere.
> [...]
>
> >
> > 8- Probably more I've already forgotten about :) Cross-compilation may
> > be interesting for build testing in the future. For the full AI created
> > commentary, there's https://github.com/joe-lawrence/linux/blob/klp-build-selftests/README.md
>
> Yes, cross-compilation can be really useful.
>
Agreed (I think Josh may be working on arm64 klp-build?) how many
dimensions of testing are we up to now :)
> > > > I was using kpatch for testing. I can replace it with insmod.
> > >
> >
> > Do the helpers in functions.sh for safely loading and unloading
> > livepatches (that wait for the transition, etc.) aid here?
>
> Yes, we can reuse those.
> [...]
>
> > To continue the bike shedding, in my branch, I had dumped this all under
> > a new tools/testing/klp-build subdirectory as my focus was to put
> > klp-build through the paces. It does load the generated livepatches in
> > the runtime testing, but as only as a sanity check. With that, it
> > didn't touch CONFIG or intermix testing with the livepatch/ set.
> >
> > If we do end up supplementing the livepatch/ with klp-build tests, then
> > I agree that naming them (either filename prefix or subdirectory) would
> > be nice.
> >
> > But first, is it goal for klp-build to be the build tool (rather than
> > simple module kbuild) for the livepatching .ko selftests?
>
> I think we don't have to use klp-build for livepatch selftests. Existing
> tests work well as-is.
>
--
Joe
^ permalink raw reply
* Re: [PATCH v3 01/13] objtool/klp: honor SHF_MERGE entry alignment in elf_add_data()
From: Josh Poimboeuf @ 2026-03-05 2:33 UTC (permalink / raw)
To: Joe Lawrence
Cc: live-patching, Song Liu, Jiri Kosina, Miroslav Benes, Petr Mladek
In-Reply-To: <aZST2WmYD-B_o0oc@redhat.com>
On Tue, Feb 17, 2026 at 11:14:17AM -0500, Joe Lawrence wrote:
> On Tue, Feb 17, 2026 at 11:06:32AM -0500, Joe Lawrence wrote:
> > When adding data to an SHF_MERGE section, set the Elf_Data d_align to
> > the section's sh_addralign so libelf aligns entries within the section.
> > This ensures that entry offsets are consistent with previously calculated
> > relocation addends.
> >
> > Fixes: 431dbabf2d9d ("objtool: Add elf_create_data()")
> > Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
> > ---
> > tools/objtool/elf.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
> > index 2c02c7b49265..bd6502e7bdc0 100644
> > --- a/tools/objtool/elf.c
> > +++ b/tools/objtool/elf.c
> > @@ -1375,7 +1375,7 @@ void *elf_add_data(struct elf *elf, struct section *sec, const void *data, size_
> > memcpy(sec->data->d_buf, data, size);
> >
> > sec->data->d_size = size;
> > - sec->data->d_align = 1;
> > + sec->data->d_align = (sec->sh.sh_flags & SHF_MERGE) ? sec->sh.sh_addralign : 1;
> >
> > offset = ALIGN(sec->sh.sh_size, sec->sh.sh_addralign);
> > sec->sh.sh_size = offset + size;
> > --
> > 2.53.0
> >
> >
>
> This one stretches my ELF internals knowledge a bit, is ^^ true or
> should we rely on the section ".str1.8" suffix to indicate internal
> alignment?
I hit the same issue in my testing for the klp-build arm64 port, I think
it can be simplified to the below?
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
@@ -1375,7 +1382,7 @@ void *elf_add_data(struct elf *elf, struct section *sec, const void *data, size_
memcpy(sec->data->d_buf, data, size);
sec->data->d_size = size;
- sec->data->d_align = 1;
+ sec->data->d_align = sec->sh.sh_addralign;
offset = ALIGN(sec->sh.sh_size, sec->sh.sh_addralign);
sec->sh.sh_size = offset + size;
^ permalink raw reply
* [PATCH 00/14] objtool/arm64: Port klp-build to arm64
From: Josh Poimboeuf @ 2026-03-05 3:31 UTC (permalink / raw)
To: x86
Cc: linux-kernel, live-patching, Peter Zijlstra, Joe Lawrence,
Song Liu, Catalin Marinas, Will Deacon, linux-arm-kernel,
Mark Rutland, Nathan Chancellor, Nicolas Schier, Herbert Xu
Port objtool and the klp-build tooling (for building livepatch modules)
to arm64.
Note this doesn't bring all the objtool bells and whistles to arm64, nor
any of the CFG reverse engineering. This only adds the bare minimum
needed for 'objtool --checksum'.
And note that objtool still doesn't get enabled at all for normal arm64
kernel builds, so this doesn't affect any users other than those running
klp-build directly.
Josh Poimboeuf (14):
objtool: Fix data alignment in elf_add_data()
objtool: Fix ERROR_INSN() error message
arm64: Annotate intra-function calls
arm64: head: Move boot header to .head.data
arm64: Fix EFI linking with -fdata-sections
crypto: arm64: Move data to .rodata
objtool: Extricate checksum calculation from validate_branch()
objtool: Allow setting --mnop without --mcount
kbuild: Only run objtool if there is at least one command
objtool: Ignore jumps to the end of the function for non-CFG arches
objtool: Allow empty alternatives
objtool: Reuse consecutive string references
objtool: Introduce objtool for arm64
klp-build: Support cross-compilation
arch/arm64/Kconfig | 2 +
arch/arm64/kernel/entry.S | 2 +
arch/arm64/kernel/head.S | 2 +-
arch/arm64/kernel/proton-pack.c | 12 +-
arch/arm64/kernel/vmlinux.lds.S | 2 +-
arch/x86/boot/startup/Makefile | 2 +-
include/asm-generic/vmlinux.lds.h | 2 +-
include/linux/init.h | 1 +
lib/crypto/arm64/sha2-armv8.pl | 11 +-
scripts/Makefile.build | 4 +-
scripts/Makefile.lib | 46 +++----
scripts/Makefile.vmlinux_o | 15 +--
scripts/livepatch/klp-build | 11 +-
tools/objtool/Makefile | 4 +
tools/objtool/arch/arm64/Build | 2 +
tools/objtool/arch/arm64/decode.c | 116 ++++++++++++++++++
.../arch/arm64/include/arch/cfi_regs.h | 11 ++
tools/objtool/arch/arm64/include/arch/elf.h | 13 ++
.../objtool/arch/arm64/include/arch/special.h | 21 ++++
tools/objtool/arch/arm64/special.c | 21 ++++
tools/objtool/builtin-check.c | 5 -
tools/objtool/check.c | 83 +++++++++----
tools/objtool/elf.c | 11 +-
tools/objtool/include/objtool/checksum.h | 6 +-
tools/objtool/include/objtool/warn.h | 2 +-
25 files changed, 323 insertions(+), 84 deletions(-)
create mode 100644 tools/objtool/arch/arm64/Build
create mode 100644 tools/objtool/arch/arm64/decode.c
create mode 100644 tools/objtool/arch/arm64/include/arch/cfi_regs.h
create mode 100644 tools/objtool/arch/arm64/include/arch/elf.h
create mode 100644 tools/objtool/arch/arm64/include/arch/special.h
create mode 100644 tools/objtool/arch/arm64/special.c
--
2.53.0
^ permalink raw reply
* [PATCH 01/14] objtool: Fix data alignment in elf_add_data()
From: Josh Poimboeuf @ 2026-03-05 3:31 UTC (permalink / raw)
To: x86
Cc: linux-kernel, live-patching, Peter Zijlstra, Joe Lawrence,
Song Liu, Catalin Marinas, Will Deacon, linux-arm-kernel,
Mark Rutland, Nathan Chancellor, Nicolas Schier, Herbert Xu
In-Reply-To: <cover.1772681234.git.jpoimboe@kernel.org>
Any data added to a section needs to be aligned in accordance with the
section's sh_addralign value. Particularly strings added to a .str1.8
section. Otherwise you may get some funky strings.
Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files")
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
tools/objtool/elf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index 2c02c7b49265..3da90686350d 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -1375,7 +1375,7 @@ void *elf_add_data(struct elf *elf, struct section *sec, const void *data, size_
memcpy(sec->data->d_buf, data, size);
sec->data->d_size = size;
- sec->data->d_align = 1;
+ sec->data->d_align = sec->sh.sh_addralign;
offset = ALIGN(sec->sh.sh_size, sec->sh.sh_addralign);
sec->sh.sh_size = offset + size;
--
2.53.0
^ permalink raw reply related
* [PATCH 02/14] objtool: Fix ERROR_INSN() error message
From: Josh Poimboeuf @ 2026-03-05 3:31 UTC (permalink / raw)
To: x86
Cc: linux-kernel, live-patching, Peter Zijlstra, Joe Lawrence,
Song Liu, Catalin Marinas, Will Deacon, linux-arm-kernel,
Mark Rutland, Nathan Chancellor, Nicolas Schier, Herbert Xu
In-Reply-To: <cover.1772681234.git.jpoimboe@kernel.org>
Confusingly, ERROR_INSN() shows "warning:" instead of "error:". Fix that.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
tools/objtool/include/objtool/warn.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/objtool/include/objtool/warn.h b/tools/objtool/include/objtool/warn.h
index 2b27b54096b8..fa8b7d292e83 100644
--- a/tools/objtool/include/objtool/warn.h
+++ b/tools/objtool/include/objtool/warn.h
@@ -107,7 +107,7 @@ static inline char *offstr(struct section *sec, unsigned long offset)
#define ERROR_ELF(format, ...) __WARN_ELF(ERROR_STR, format, ##__VA_ARGS__)
#define ERROR_GLIBC(format, ...) __WARN_GLIBC(ERROR_STR, format, ##__VA_ARGS__)
#define ERROR_FUNC(sec, offset, format, ...) __WARN_FUNC(ERROR_STR, sec, offset, format, ##__VA_ARGS__)
-#define ERROR_INSN(insn, format, ...) WARN_FUNC(insn->sec, insn->offset, format, ##__VA_ARGS__)
+#define ERROR_INSN(insn, format, ...) ERROR_FUNC(insn->sec, insn->offset, format, ##__VA_ARGS__)
extern bool debug;
extern int indent;
--
2.53.0
^ permalink raw reply related
* [PATCH 03/14] arm64: Annotate intra-function calls
From: Josh Poimboeuf @ 2026-03-05 3:31 UTC (permalink / raw)
To: x86
Cc: linux-kernel, live-patching, Peter Zijlstra, Joe Lawrence,
Song Liu, Catalin Marinas, Will Deacon, linux-arm-kernel,
Mark Rutland, Nathan Chancellor, Nicolas Schier, Herbert Xu
In-Reply-To: <cover.1772681234.git.jpoimboe@kernel.org>
In preparation for enabling objtool on arm64, annotate intra-function
calls.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
arch/arm64/kernel/entry.S | 2 ++
arch/arm64/kernel/proton-pack.c | 12 +++++++-----
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index f8018b5c1f9a..cf808bb2abc0 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -10,6 +10,7 @@
#include <linux/arm-smccc.h>
#include <linux/init.h>
#include <linux/linkage.h>
+#include <linux/annotate.h>
#include <asm/alternative.h>
#include <asm/assembler.h>
@@ -707,6 +708,7 @@ alternative_else_nop_endif
* entry onto the return stack and using a RET instruction to
* enter the full-fat kernel vectors.
*/
+ ANNOTATE_INTRA_FUNCTION_CALL
bl 2f
b .
2:
diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c
index b3801f532b10..b63887a1b823 100644
--- a/arch/arm64/kernel/proton-pack.c
+++ b/arch/arm64/kernel/proton-pack.c
@@ -24,6 +24,7 @@
#include <linux/nospec.h>
#include <linux/prctl.h>
#include <linux/sched/task_stack.h>
+#include <linux/annotate.h>
#include <asm/debug-monitors.h>
#include <asm/insn.h>
@@ -245,11 +246,12 @@ static noinstr void qcom_link_stack_sanitisation(void)
{
u64 tmp;
- asm volatile("mov %0, x30 \n"
- ".rept 16 \n"
- "bl . + 4 \n"
- ".endr \n"
- "mov x30, %0 \n"
+ asm volatile("mov %0, x30 \n"
+ ".rept 16 \n"
+ ANNOTATE_INTRA_FUNCTION_CALL " \n"
+ "bl . + 4 \n"
+ ".endr \n"
+ "mov x30, %0 \n"
: "=&r" (tmp));
}
--
2.53.0
^ permalink raw reply related
* [PATCH 04/14] arm64: head: Move boot header to .head.data
From: Josh Poimboeuf @ 2026-03-05 3:31 UTC (permalink / raw)
To: x86
Cc: linux-kernel, live-patching, Peter Zijlstra, Joe Lawrence,
Song Liu, Catalin Marinas, Will Deacon, linux-arm-kernel,
Mark Rutland, Nathan Chancellor, Nicolas Schier, Herbert Xu
In-Reply-To: <cover.1772681234.git.jpoimboe@kernel.org>
The arm64 boot header is mostly data. Move it to a data section to
prevent objtool and other tools from trying to disassemble it. The
final linked result is the same.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
arch/arm64/kernel/head.S | 2 +-
include/asm-generic/vmlinux.lds.h | 2 +-
include/linux/init.h | 1 +
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 87a822e5c4ca..0681c6e50859 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -54,7 +54,7 @@
* that are useful before the MMU is enabled. The allocations are described
* in the entry routines.
*/
- __HEAD
+ __HEADDATA
/*
* DO NOT MODIFY. Image header expected by Linux boot-loaders.
*/
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index eeb070f330bd..51a0e5974f41 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -663,7 +663,7 @@
__static_call_text_end = .;
/* Section used for early init (in .S files) */
-#define HEAD_TEXT KEEP(*(.head.text))
+#define HEAD_TEXT KEEP(*(.head.data .head.text))
#define HEAD_TEXT_SECTION \
.head.text : AT(ADDR(.head.text) - LOAD_OFFSET) { \
diff --git a/include/linux/init.h b/include/linux/init.h
index 40331923b9f4..91e16f3205e2 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -90,6 +90,7 @@
/* For assembly routines */
#define __HEAD .section ".head.text","ax"
+#define __HEADDATA .section ".head.data","aw"
#define __INIT .section ".init.text","ax"
#define __FINIT .previous
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox