* Re: [PATCH 3/5] objtool/klp: validate patches with git apply --recount
From: Song Liu @ 2026-02-03 17:53 UTC (permalink / raw)
To: Joe Lawrence
Cc: Josh Poimboeuf, live-patching, Jiri Kosina, Miroslav Benes,
Petr Mladek
In-Reply-To: <604a8b96-47f2-4986-b602-c7bdf3de7cca@redhat.com>
On Tue, Feb 3, 2026 at 8:45 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
[...]
> > Or at least validate_patches() could be replaced with
> > check_unsupported_patches(), as the apply/revert test wouldn't be needed
> > since the actual apply/revert would happen immediately after that in
> > fix_patches().
> >
>
> Currently fix_patches runs in short-circuit step (2) after building the
> original kernel. But what if the user runs:
>
> $ klp-build -T 0001.patch
> $ klp-build -S 2 0002.patch
On one hand, I think this is a user mistake that we need the users
to avoid by themselves. If the user do
$ klp-build -T 0001.patch
$ klp-build -S 3 0002.patch
Even when 0001.patch and 0002.patch are totally valid, the end
result will be very confusing (it is the result of 0001.patch, not 0002).
> If we move fix_patches() to step (1) to fail fast and eliminate a
> redundant apply/revert, aren't we then going to miss it if the user
> jumps to step (2)?
>
> Is there a way to check without actually doing it if we're going to
> build the original kernel first?
>
> And while we're here, doesn't this mean that we're currently not running
> validate_patches() when skipping to step (2)?
On the other hand, I guess we can always run fix_patches. If any
-S is given, we compare the fixed new patches against fixed saved
patches. If they are not identical, we fail fast.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH 3/5] objtool/klp: validate patches with git apply --recount
From: Joe Lawrence @ 2026-02-03 16:45 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: live-patching, Jiri Kosina, Miroslav Benes, Petr Mladek
In-Reply-To: <72pzjkj4vnp2vp4ekbj3wnjr62yuywk67tavzn27zetmkg2tjh@nkpihey5cc3g>
On 1/30/26 6:02 PM, Josh Poimboeuf wrote:
> On Fri, Jan 30, 2026 at 02:59:53PM -0800, Josh Poimboeuf wrote:
>> On Fri, Jan 30, 2026 at 03:38:40PM -0500, Joe Lawrence wrote:
>>> On Fri, Jan 30, 2026 at 12:05:35PM -0800, Josh Poimboeuf wrote:
>>>> Hm, isn't the whole point of --recount that it ignores the line numbers?
>>>> Or does it just ignore the numbers after the commas (the counts)?
>>>>
>>>
>>> I don't know exactly. As I continue digging into the test that sent me
>>> down this path, I just found that `git apply --recount` doesn't like
>>> some output generated by `combinediff -q --combine` even with NO line
>>> drift... then if I manually added in corresponding diff command lines
>>> (to make it look more like a .patch file generated by `diff -Nu`), ie:
>>>
>>> diff -Nu src.orig/fs/proc/array.c src/fs/proc/array.c <---
>>> --- src.orig/fs/proc/array.c
>>> +++ src/fs/proc/array.c
>>>
>>> Suddenly `git apply --recount` is happy with the patch.
>>>
>>> So I suspect that I started with git not liking the hunks generated by
>>> combinediff and drove it to the rebase feature, which solves a more
>>> interesting problem, but by side effect smoothed over this format
>>> issue when it recreated the patch with git.
>>>
>>> Anyway, I think this patch still stands on it's own: perform the same
>>> apply/revert check as what would happen in the fixup steps to fail
>>> faster for the user?
>>
>> If we just run fix_patches() at the beginning then can we just get rid
>> of validate_patches() altogether?
>
> Or at least validate_patches() could be replaced with
> check_unsupported_patches(), as the apply/revert test wouldn't be needed
> since the actual apply/revert would happen immediately after that in
> fix_patches().
>
Currently fix_patches runs in short-circuit step (2) after building the
original kernel. But what if the user runs:
$ klp-build -T 0001.patch
$ klp-build -S 2 0002.patch
If we move fix_patches() to step (1) to fail fast and eliminate a
redundant apply/revert, aren't we then going to miss it if the user
jumps to step (2)?
Is there a way to check without actually doing it if we're going to
build the original kernel first?
And while we're here, doesn't this mean that we're currently not running
validate_patches() when skipping to step (2)?
--
Joe
^ permalink raw reply
* Re: [PATCH v3 0/2] Improve handling of the __klp_{objects,funcs} sections in modules
From: Miroslav Benes @ 2026-02-03 10:24 UTC (permalink / raw)
To: Petr Pavlu
Cc: Josh Poimboeuf, Jiri Kosina, Petr Mladek, Joe Lawrence,
Luis Chamberlain, Daniel Gomez, Sami Tolvanen, Aaron Tomlin,
Peter Zijlstra, live-patching, linux-modules, linux-kernel
In-Reply-To: <20260123102825.3521961-1-petr.pavlu@suse.com>
On Fri, 23 Jan 2026, Petr Pavlu wrote:
> Changes since v2 [1]:
> - Generalize the helper function that locates __klp_objects in a module
> to allow it to find any data in other sections as well.
>
> Changes since v1 [2]:
> - Generalize the helper function that locates __klp_objects in a module
> to allow it to find objects in other sections as well.
>
> [1] https://lore.kernel.org/linux-modules/20260121082842.3050453-1-petr.pavlu@suse.com/
> [2] https://lore.kernel.org/linux-modules/20260114123056.2045816-1-petr.pavlu@suse.com/
>
> Petr Pavlu (2):
> livepatch: Fix having __klp_objects relics in non-livepatch modules
> livepatch: Free klp_{object,func}_ext data after initialization
>
> include/linux/livepatch.h | 3 +++
> kernel/livepatch/core.c | 19 +++++++++++++++++++
> scripts/livepatch/init.c | 20 +++++++++-----------
> scripts/module.lds.S | 9 ++-------
> tools/objtool/check.c | 2 +-
> tools/objtool/include/objtool/klp.h | 10 +++++-----
> tools/objtool/klp-diff.c | 2 +-
> 7 files changed, 40 insertions(+), 25 deletions(-)
>
>
> base-commit: 0f61b1860cc3f52aef9036d7235ed1f017632193
Acked-by: Miroslav Benes <mbenes@suse.cz>
Thank you,
M
^ permalink raw reply
* Re: [PATCH] objtool/klp: Fix unexported static call key access for manually built livepatch modules
From: Song Liu @ 2026-02-02 21:59 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: x86, linux-kernel, live-patching, Peter Zijlstra, Arnd Bergmann
In-Reply-To: <0bd3ae9a53c3d743417fe842b740a7720e2bcd1c.1770058775.git.jpoimboe@kernel.org>
On Mon, Feb 2, 2026 at 11:00 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> Enabling CONFIG_MEM_ALLOC_PROFILING_DEBUG with CONFIG_SAMPLE_LIVEPATCH
> results in the following error:
>
> samples/livepatch/livepatch-shadow-fix1.o: error: objtool: static_call: can't find static_call_key symbol: __SCK__WARN_trap
>
> This is caused an extra file->klp sanity check which was added by commit
> 164c9201e1da ("objtool: Add base objtool support for livepatch
> modules"). That check was intended to ensure that livepatch modules
> built with klp-build always have full access to their static call keys.
>
> However, it failed to account for the fact that manually built livepatch
> modules (i.e., not built with klp-build) might need access to unexported
> static call keys, for which read-only access is typically allowed for
> modules.
>
> While the livepatch-shadow-fix1 module doesn't explicitly use any static
> calls, it does have a memory allocation, which can cause
> CONFIG_MEM_ALLOC_PROFILING_DEBUG to insert a WARN() call. And WARN() is
> now an unexported static call as of commit 860238af7a33 ("x86_64/bug:
> Inline the UD1").
>
> Fix it by removing the overzealous file->klp check, restoring the
> original behavior for manually built livepatch modules.
>
> Fixes: 164c9201e1da ("objtool: Add base objtool support for livepatch modules")
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Acked-by: Song Liu <song@kernel.org>
^ permalink raw reply
* Re: [PATCH] objtool/klp: Fix symbol correlation for orphaned local symbols
From: Song Liu @ 2026-02-02 21:56 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: x86, linux-kernel, live-patching, Peter Zijlstra
In-Reply-To: <e21ec1141fc749b5f538d7329b531c1ab63a6d1a.1770055235.git.jpoimboe@kernel.org>
On Mon, Feb 2, 2026 at 10:01 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> When compiling with CONFIG_LTO_CLANG_THIN, vmlinux.o has
> __irf_[start|end] before the first FILE entry:
>
> $ readelf -sW vmlinux.o
> Symbol table '.symtab' contains 597706 entries:
> Num: Value Size Type Bind Vis Ndx Name
> 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
> 1: 0000000000000000 0 NOTYPE LOCAL DEFAULT 18 __irf_start
> 2: 0000000000000200 0 NOTYPE LOCAL DEFAULT 18 __irf_end
> 3: 0000000000000000 0 SECTION LOCAL DEFAULT 17 .text
> 4: 0000000000000000 0 SECTION LOCAL DEFAULT 18 .init.ramfs
>
> This causes klp-build warnings like:
>
> vmlinux.o: warning: objtool: no correlation: __irf_start
> vmlinux.o: warning: objtool: no correlation: __irf_end
>
> The problem is that Clang LTO is stripping the initramfs_data.o FILE
> symbol, causing those two symbols to be orphaned and not noticed by
> klp-diff's correlation logic. Add a loop to correlate any symbols found
> before the first FILE symbol.
>
> Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files")
> Reported-by: Song Liu <song@kernel.org>
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Acked-by: Song Liu <song@kernel.org>
^ permalink raw reply
* Re: [PATCH] objtool/klp: Fix unexported static call key access for manually built livepatch modules
From: Arnd Bergmann @ 2026-02-02 20:10 UTC (permalink / raw)
To: Josh Poimboeuf, x86; +Cc: linux-kernel, live-patching, Peter Zijlstra
In-Reply-To: <0bd3ae9a53c3d743417fe842b740a7720e2bcd1c.1770058775.git.jpoimboe@kernel.org>
On Mon, Feb 2, 2026, at 20:00, Josh Poimboeuf wrote:
> Enabling CONFIG_MEM_ALLOC_PROFILING_DEBUG with CONFIG_SAMPLE_LIVEPATCH
> results in the following error:
>
> samples/livepatch/livepatch-shadow-fix1.o: error: objtool:
> static_call: can't find static_call_key symbol: __SCK__WARN_trap
>
> This is caused an extra file->klp sanity check which was added by commit
> 164c9201e1da ("objtool: Add base objtool support for livepatch
> modules"). That check was intended to ensure that livepatch modules
> built with klp-build always have full access to their static call keys.
>
> However, it failed to account for the fact that manually built livepatch
> modules (i.e., not built with klp-build) might need access to unexported
> static call keys, for which read-only access is typically allowed for
> modules.
>
> While the livepatch-shadow-fix1 module doesn't explicitly use any static
> calls, it does have a memory allocation, which can cause
> CONFIG_MEM_ALLOC_PROFILING_DEBUG to insert a WARN() call. And WARN() is
> now an unexported static call as of commit 860238af7a33 ("x86_64/bug:
> Inline the UD1").
>
> Fix it by removing the overzealous file->klp check, restoring the
> original behavior for manually built livepatch modules.
>
> Fixes: 164c9201e1da ("objtool: Add base objtool support for livepatch modules")
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Tested-by: Arnd Bergmann <arnd@arndb.de>
Thanks a lot for the fix!
Arnd
^ permalink raw reply
* [PATCH] objtool/klp: Fix unexported static call key access for manually built livepatch modules
From: Josh Poimboeuf @ 2026-02-02 19:00 UTC (permalink / raw)
To: x86; +Cc: linux-kernel, live-patching, Peter Zijlstra, Arnd Bergmann
Enabling CONFIG_MEM_ALLOC_PROFILING_DEBUG with CONFIG_SAMPLE_LIVEPATCH
results in the following error:
samples/livepatch/livepatch-shadow-fix1.o: error: objtool: static_call: can't find static_call_key symbol: __SCK__WARN_trap
This is caused an extra file->klp sanity check which was added by commit
164c9201e1da ("objtool: Add base objtool support for livepatch
modules"). That check was intended to ensure that livepatch modules
built with klp-build always have full access to their static call keys.
However, it failed to account for the fact that manually built livepatch
modules (i.e., not built with klp-build) might need access to unexported
static call keys, for which read-only access is typically allowed for
modules.
While the livepatch-shadow-fix1 module doesn't explicitly use any static
calls, it does have a memory allocation, which can cause
CONFIG_MEM_ALLOC_PROFILING_DEBUG to insert a WARN() call. And WARN() is
now an unexported static call as of commit 860238af7a33 ("x86_64/bug:
Inline the UD1").
Fix it by removing the overzealous file->klp check, restoring the
original behavior for manually built livepatch modules.
Fixes: 164c9201e1da ("objtool: Add base objtool support for livepatch modules")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
tools/objtool/check.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 933868ee3beb..ef451cd6277c 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -682,7 +682,7 @@ static int create_static_call_sections(struct objtool_file *file)
key_sym = find_symbol_by_name(file->elf, tmp);
if (!key_sym) {
- if (!opts.module || file->klp) {
+ if (!opts.module) {
ERROR("static_call: can't find static_call_key symbol: %s", tmp);
return -1;
}
--
2.52.0
^ permalink raw reply related
* Re: objtool: static_call: can't find static_call_key symbol: __SCK__WARN_trap
From: Josh Poimboeuf @ 2026-02-02 18:26 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Peter Zijlstra, x86, linux-kernel, live-patching
In-Reply-To: <puebtzhzzstmcdufv3deh2twxflheqf6b6opkmw4rfjfua67ns@gbkkboyglhpt>
On Mon, Feb 02, 2026 at 10:20:15AM -0800, Josh Poimboeuf wrote:
> On Mon, Feb 02, 2026 at 10:19:33AM -0800, Josh Poimboeuf wrote:
> > On Mon, Feb 02, 2026 at 05:18:13PM +0100, Arnd Bergmann wrote:
> > > Hi,
> > >
> > > I see a new objtool related build failure on current linux-next
> > > with clang-21:
> > >
> > > samples/livepatch/livepatch-shadow-fix1.o: error: objtool: static_call: can't find static_call_key symbol: __SCK__WARN_trap
> > >
> > > I couldn't figure out what exactly is going on there, this seems fine
> > > with gcc, and so far only one of hundreds of configs has this issue.
> > >
> > > See the attachments for .config and the object file.
> >
> > Ah, this is CONFIG_MEM_ALLOC_PROFILING_DEBUG inserting a WARN() in the
> > sample livepatch module's memory allocation, triggering the following
> > warning (file->klp is true):
> >
> > if (!key_sym) {
> > if (!opts.module || file->klp) {
> > ERROR("static_call: can't find static_call_key symbol: %s", tmp);
> > return -1;
> > }
> >
> >
> > So this is showing that the sample livepatch modules (which are built
> > differently from the new klp-build way of building livepatch modules)
> > will fail to build when trying to access a non-exported static key.
>
> Erm, non-exported static *call*.
So I think we can just remove that file->klp check. That check is
perhaps a bit too strict since it doesn't take into account livepatch
modules that were built without klp-build.
--
Josh
^ permalink raw reply
* Re: objtool: static_call: can't find static_call_key symbol: __SCK__WARN_trap
From: Josh Poimboeuf @ 2026-02-02 18:20 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Peter Zijlstra, x86, linux-kernel, live-patching
In-Reply-To: <dbbcybceshl7xlj2qujmo6s2vha7oqvp6bqcir5jfjae7h2z7b@iy4uzb2ygunj>
On Mon, Feb 02, 2026 at 10:19:33AM -0800, Josh Poimboeuf wrote:
> On Mon, Feb 02, 2026 at 05:18:13PM +0100, Arnd Bergmann wrote:
> > Hi,
> >
> > I see a new objtool related build failure on current linux-next
> > with clang-21:
> >
> > samples/livepatch/livepatch-shadow-fix1.o: error: objtool: static_call: can't find static_call_key symbol: __SCK__WARN_trap
> >
> > I couldn't figure out what exactly is going on there, this seems fine
> > with gcc, and so far only one of hundreds of configs has this issue.
> >
> > See the attachments for .config and the object file.
>
> Ah, this is CONFIG_MEM_ALLOC_PROFILING_DEBUG inserting a WARN() in the
> sample livepatch module's memory allocation, triggering the following
> warning (file->klp is true):
>
> if (!key_sym) {
> if (!opts.module || file->klp) {
> ERROR("static_call: can't find static_call_key symbol: %s", tmp);
> return -1;
> }
>
>
> So this is showing that the sample livepatch modules (which are built
> differently from the new klp-build way of building livepatch modules)
> will fail to build when trying to access a non-exported static key.
Erm, non-exported static *call*.
--
Josh
^ permalink raw reply
* Re: objtool: static_call: can't find static_call_key symbol: __SCK__WARN_trap
From: Josh Poimboeuf @ 2026-02-02 18:19 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Peter Zijlstra, x86, linux-kernel, live-patching
In-Reply-To: <99f7cfd4-ef1a-4da6-842f-19429b1fb2d2@app.fastmail.com>
On Mon, Feb 02, 2026 at 05:18:13PM +0100, Arnd Bergmann wrote:
> Hi,
>
> I see a new objtool related build failure on current linux-next
> with clang-21:
>
> samples/livepatch/livepatch-shadow-fix1.o: error: objtool: static_call: can't find static_call_key symbol: __SCK__WARN_trap
>
> I couldn't figure out what exactly is going on there, this seems fine
> with gcc, and so far only one of hundreds of configs has this issue.
>
> See the attachments for .config and the object file.
Ah, this is CONFIG_MEM_ALLOC_PROFILING_DEBUG inserting a WARN() in the
sample livepatch module's memory allocation, triggering the following
warning (file->klp is true):
if (!key_sym) {
if (!opts.module || file->klp) {
ERROR("static_call: can't find static_call_key symbol: %s", tmp);
return -1;
}
So this is showing that the sample livepatch modules (which are built
differently from the new klp-build way of building livepatch modules)
will fail to build when trying to access a non-exported static key.
I will need to stare at that a bit to try to figure out a fix.
--
Josh
^ permalink raw reply
* [PATCH] objtool/klp: Fix symbol correlation for orphaned local symbols
From: Josh Poimboeuf @ 2026-02-02 18:01 UTC (permalink / raw)
To: x86; +Cc: linux-kernel, live-patching, Peter Zijlstra, Song Liu
When compiling with CONFIG_LTO_CLANG_THIN, vmlinux.o has
__irf_[start|end] before the first FILE entry:
$ readelf -sW vmlinux.o
Symbol table '.symtab' contains 597706 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 NOTYPE LOCAL DEFAULT 18 __irf_start
2: 0000000000000200 0 NOTYPE LOCAL DEFAULT 18 __irf_end
3: 0000000000000000 0 SECTION LOCAL DEFAULT 17 .text
4: 0000000000000000 0 SECTION LOCAL DEFAULT 18 .init.ramfs
This causes klp-build warnings like:
vmlinux.o: warning: objtool: no correlation: __irf_start
vmlinux.o: warning: objtool: no correlation: __irf_end
The problem is that Clang LTO is stripping the initramfs_data.o FILE
symbol, causing those two symbols to be orphaned and not noticed by
klp-diff's correlation logic. Add a loop to correlate any symbols found
before the first FILE symbol.
Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for diffing object files")
Reported-by: Song Liu <song@kernel.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
---
tools/objtool/klp-diff.c | 39 ++++++++++++++++++++++++++++++++++-----
1 file changed, 34 insertions(+), 5 deletions(-)
diff --git a/tools/objtool/klp-diff.c b/tools/objtool/klp-diff.c
index 1e649a3eb4cd..9f1f4011eb9c 100644
--- a/tools/objtool/klp-diff.c
+++ b/tools/objtool/klp-diff.c
@@ -364,11 +364,40 @@ static int correlate_symbols(struct elfs *e)
struct symbol *file1_sym, *file2_sym;
struct symbol *sym1, *sym2;
- /* Correlate locals */
- for (file1_sym = first_file_symbol(e->orig),
- file2_sym = first_file_symbol(e->patched); ;
- file1_sym = next_file_symbol(e->orig, file1_sym),
- file2_sym = next_file_symbol(e->patched, file2_sym)) {
+ file1_sym = first_file_symbol(e->orig);
+ file2_sym = first_file_symbol(e->patched);
+
+ /*
+ * Correlate any locals before the first FILE symbol. This has been
+ * seen when LTO inexplicably strips the initramfs_data.o FILE symbol
+ * due to the file only containing data and no code.
+ */
+ for_each_sym(e->orig, sym1) {
+ if (sym1 == file1_sym || !is_local_sym(sym1))
+ break;
+
+ if (dont_correlate(sym1))
+ continue;
+
+ for_each_sym(e->patched, sym2) {
+ if (sym2 == file2_sym || !is_local_sym(sym2))
+ break;
+
+ if (sym2->twin || dont_correlate(sym2))
+ continue;
+
+ if (strcmp(sym1->demangled_name, sym2->demangled_name))
+ continue;
+
+ sym1->twin = sym2;
+ sym2->twin = sym1;
+ break;
+ }
+ }
+
+ /* Correlate locals after the first FILE symbol */
+ for (; ; file1_sym = next_file_symbol(e->orig, file1_sym),
+ file2_sym = next_file_symbol(e->patched, file2_sym)) {
if (!file1_sym && file2_sym) {
ERROR("FILE symbol mismatch: NULL != %s", file2_sym->name);
--
2.52.0
^ permalink raw reply related
* [PATCH] klp: use stop machine to check and expedite transition for running tasks
From: Li Zhe @ 2026-02-02 9:13 UTC (permalink / raw)
To: jpoimboe, jikos, mbenes, pmladek, joe.lawrence
Cc: live-patching, linux-kernel, lizhe.67, qirui.001
In the current KLP transition implementation, the strategy for running
tasks relies on waiting for a context switch to attempt to clear the
TIF_PATCH_PENDING flag. Alternatively, determine whether the
TIF_PATCH_PENDING flag can be cleared by inspecting the stack once the
process has yielded the CPU. However, this approach proves problematic
in certain environments.
Consider a scenario where the majority of system CPUs are configured
with nohzfull and isolcpus, each dedicated to a VM with a vCPU pinned
to that physical core and configured with idle=poll within the guest.
Under such conditions, these vCPUs rarely leave the CPU. Combined with
the high core counts typical of modern server platforms, this results
in transition completion times that are not only excessively prolonged
but also highly unpredictable.
This patch resolves this issue by registering a callback with
stop_machine. The callback attempts to transition the associated running
task. In a VM environment configured with 32 CPUs, the live patching
operation completes promptly after the SIGNALS_TIMEOUT period with this
patch applied; without it, the process nearly fails to complete under
the same scenario.
Co-developed-by: Rui Qi <qirui.001@bytedance.com>
Signed-off-by: Rui Qi <qirui.001@bytedance.com>
Signed-off-by: Li Zhe <lizhe.67@bytedance.com>
---
kernel/livepatch/transition.c | 62 ++++++++++++++++++++++++++++++++---
1 file changed, 58 insertions(+), 4 deletions(-)
diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c
index 2351a19ac2a9..9c078b9bd755 100644
--- a/kernel/livepatch/transition.c
+++ b/kernel/livepatch/transition.c
@@ -10,6 +10,7 @@
#include <linux/cpu.h>
#include <linux/stacktrace.h>
#include <linux/static_call.h>
+#include <linux/stop_machine.h>
#include "core.h"
#include "patch.h"
#include "transition.h"
@@ -297,6 +298,61 @@ static int klp_check_and_switch_task(struct task_struct *task, void *arg)
return 0;
}
+enum klp_stop_work_bit {
+ KLP_STOP_WORK_PENDING_BIT,
+};
+
+struct klp_stop_work_info {
+ struct task_struct *task;
+ unsigned long flag;
+};
+
+static DEFINE_PER_CPU(struct cpu_stop_work, klp_transition_stop_work);
+static DEFINE_PER_CPU(struct klp_stop_work_info, klp_stop_work_info);
+
+static int klp_check_task(struct task_struct *task, void *old_name)
+{
+ if (task == current)
+ return klp_check_and_switch_task(current, old_name);
+ else
+ return task_call_func(task, klp_check_and_switch_task, old_name);
+}
+
+static int klp_transition_stop_work_fn(void *arg)
+{
+ struct klp_stop_work_info *info = (struct klp_stop_work_info *)arg;
+ struct task_struct *task = info->task;
+ const char *old_name;
+
+ clear_bit(KLP_STOP_WORK_PENDING_BIT, &info->flag);
+
+ if (likely(klp_patch_pending(task)))
+ klp_check_task(task, &old_name);
+
+ put_task_struct(task);
+
+ return 0;
+}
+
+static void klp_try_transition_running_task(struct task_struct *task)
+{
+ int cpu = task_cpu(task);
+
+ if (klp_signals_cnt && !(klp_signals_cnt % SIGNALS_TIMEOUT)) {
+ struct klp_stop_work_info *info =
+ per_cpu_ptr(&klp_stop_work_info, cpu);
+
+ if (test_and_set_bit(KLP_STOP_WORK_PENDING_BIT, &info->flag))
+ return;
+
+ info->task = get_task_struct(task);
+ if (!stop_one_cpu_nowait(cpu, klp_transition_stop_work_fn, info,
+ per_cpu_ptr(&klp_transition_stop_work,
+ cpu)))
+ put_task_struct(task);
+ }
+}
+
/*
* Try to safely switch a task to the target patch state. If it's currently
* running, or it's sleeping on a to-be-patched or to-be-unpatched function, or
@@ -323,10 +379,7 @@ static bool klp_try_switch_task(struct task_struct *task)
* functions. If all goes well, switch the task to the target patch
* state.
*/
- if (task == current)
- ret = klp_check_and_switch_task(current, &old_name);
- else
- ret = task_call_func(task, klp_check_and_switch_task, &old_name);
+ ret = klp_check_task(task, &old_name);
switch (ret) {
case 0: /* success */
@@ -335,6 +388,7 @@ static bool klp_try_switch_task(struct task_struct *task)
case -EBUSY: /* klp_check_and_switch_task() */
pr_debug("%s: %s:%d is running\n",
__func__, task->comm, task->pid);
+ klp_try_transition_running_task(task);
break;
case -EINVAL: /* klp_check_and_switch_task() */
pr_debug("%s: %s:%d has an unreliable stack\n",
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] klp-build: Do not warn "no correlation" for __irf_[start|end]
From: Song Liu @ 2026-02-01 4:26 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: live-patching, kernel-team, jikos, mbenes, pmladek, joe.lawrence
In-Reply-To: <2ngp5g3ogtin57nytfvbiq2nh6nfy5qxdianll5eme24owsyj5@a4bxxfkobnwc>
On Fri, Jan 30, 2026 at 6:27 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
[...]
> It's a bit worrisome that Clang is stripping FILE entries and moving
> symbols, but I looked at the symbol table for a thin LTO vmlinux.o and
> it only seems to have stripped this one FILE symbol for initramfs_data.o
> and made its symbols orphans. Presumably because this file only has
> data and no code.
>
> I actually think the warning is valid. We should try to correlate those
> pre-FILE symbols, otherwise things like klp_reloc_needed() might not
> work as intended.
>
> Does the below patch work instead?
Yes, this does look better. Let's ship this version.
Thanks,
Song
>
> diff --git a/tools/objtool/klp-diff.c b/tools/objtool/klp-diff.c
> index d94531e3f64e..ea292ebe217f 100644
> --- a/tools/objtool/klp-diff.c
> +++ b/tools/objtool/klp-diff.c
> @@ -364,11 +364,40 @@ static int correlate_symbols(struct elfs *e)
> struct symbol *file1_sym, *file2_sym;
> struct symbol *sym1, *sym2;
>
> - /* Correlate locals */
> - for (file1_sym = first_file_symbol(e->orig),
> - file2_sym = first_file_symbol(e->patched); ;
> - file1_sym = next_file_symbol(e->orig, file1_sym),
> - file2_sym = next_file_symbol(e->patched, file2_sym)) {
> + file1_sym = first_file_symbol(e->orig);
> + file2_sym = first_file_symbol(e->patched);
> +
> + /*
> + * Correlate any locals before the first FILE symbol. This has been
> + * seen when LTO inexplicably strips the initramfs_data.o FILE symbol
> + * due to the file only containing data and no code.
> + */
> + for_each_sym(e->orig, sym1) {
> + if (sym1 == file1_sym || !is_local_sym(sym1))
> + break;
> +
> + if (dont_correlate(sym1))
> + continue;
> +
> + for_each_sym(e->patched, sym2) {
> + if (sym2 == file2_sym || !is_local_sym(sym2))
> + break;
> +
> + if (sym2->twin || dont_correlate(sym2))
> + continue;
> +
> + if (strcmp(sym1->demangled_name, sym2->demangled_name))
> + continue;
> +
> + sym1->twin = sym2;
> + sym2->twin = sym1;
> + break;
> + }
> + }
> +
> + /* Correlate locals after the first FILE symbol */
> + for (; ; file1_sym = next_file_symbol(e->orig, file1_sym),
> + file2_sym = next_file_symbol(e->patched, file2_sym)) {
>
> if (!file1_sym && file2_sym) {
> ERROR("FILE symbol mismatch: NULL != %s", file2_sym->name);
^ permalink raw reply
* Re: [PATCH] klp-build: Do not warn "no correlation" for __irf_[start|end]
From: Josh Poimboeuf @ 2026-01-31 2:26 UTC (permalink / raw)
To: Song Liu; +Cc: live-patching, kernel-team, jikos, mbenes, pmladek, joe.lawrence
In-Reply-To: <20260130203912.2494181-1-song@kernel.org>
On Fri, Jan 30, 2026 at 12:39:12PM -0800, Song Liu wrote:
> When compiling with CONFIG_LTO_CLANG_THIN, vmlinux.o has
> __irf_[start|end] before the first FILE entry:
>
> $ readelf -sW vmlinux.o
> Symbol table '.symtab' contains 597706 entries:
> Num: Value Size Type Bind Vis Ndx Name
> 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
> 1: 0000000000000000 0 NOTYPE LOCAL DEFAULT 18 __irf_start
> 2: 0000000000000200 0 NOTYPE LOCAL DEFAULT 18 __irf_end
> 3: 0000000000000000 0 SECTION LOCAL DEFAULT 17 .text
> 4: 0000000000000000 0 SECTION LOCAL DEFAULT 18 .init.ramfs
>
> This causes klp-build throwing warnings like:
>
> vmlinux.o: warning: objtool: no correlation: __irf_start
> vmlinux.o: warning: objtool: no correlation: __irf_end
>
> Fix this by not warn for no correlation before seeing the first FILE
> entry.
>
> Signed-off-by: Song Liu <song@kernel.org>
> ---
> tools/objtool/klp-diff.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/tools/objtool/klp-diff.c b/tools/objtool/klp-diff.c
> index d94531e3f64e..370e5c79ae66 100644
> --- a/tools/objtool/klp-diff.c
> +++ b/tools/objtool/klp-diff.c
> @@ -363,6 +363,7 @@ static int correlate_symbols(struct elfs *e)
> {
> struct symbol *file1_sym, *file2_sym;
> struct symbol *sym1, *sym2;
> + bool found_first_file = false;
>
> /* Correlate locals */
> for (file1_sym = first_file_symbol(e->orig),
> @@ -432,9 +433,12 @@ static int correlate_symbols(struct elfs *e)
> }
>
> for_each_sym(e->orig, sym1) {
> + if (!found_first_file && is_file_sym(sym1))
> + found_first_file = true;
> if (sym1->twin || dont_correlate(sym1))
> continue;
> - WARN("no correlation: %s", sym1->name);
> + if (found_first_file)
> + WARN("no correlation: %s", sym1->name);
It's a bit worrisome that Clang is stripping FILE entries and moving
symbols, but I looked at the symbol table for a thin LTO vmlinux.o and
it only seems to have stripped this one FILE symbol for initramfs_data.o
and made its symbols orphans. Presumably because this file only has
data and no code.
I actually think the warning is valid. We should try to correlate those
pre-FILE symbols, otherwise things like klp_reloc_needed() might not
work as intended.
Does the below patch work instead?
diff --git a/tools/objtool/klp-diff.c b/tools/objtool/klp-diff.c
index d94531e3f64e..ea292ebe217f 100644
--- a/tools/objtool/klp-diff.c
+++ b/tools/objtool/klp-diff.c
@@ -364,11 +364,40 @@ static int correlate_symbols(struct elfs *e)
struct symbol *file1_sym, *file2_sym;
struct symbol *sym1, *sym2;
- /* Correlate locals */
- for (file1_sym = first_file_symbol(e->orig),
- file2_sym = first_file_symbol(e->patched); ;
- file1_sym = next_file_symbol(e->orig, file1_sym),
- file2_sym = next_file_symbol(e->patched, file2_sym)) {
+ file1_sym = first_file_symbol(e->orig);
+ file2_sym = first_file_symbol(e->patched);
+
+ /*
+ * Correlate any locals before the first FILE symbol. This has been
+ * seen when LTO inexplicably strips the initramfs_data.o FILE symbol
+ * due to the file only containing data and no code.
+ */
+ for_each_sym(e->orig, sym1) {
+ if (sym1 == file1_sym || !is_local_sym(sym1))
+ break;
+
+ if (dont_correlate(sym1))
+ continue;
+
+ for_each_sym(e->patched, sym2) {
+ if (sym2 == file2_sym || !is_local_sym(sym2))
+ break;
+
+ if (sym2->twin || dont_correlate(sym2))
+ continue;
+
+ if (strcmp(sym1->demangled_name, sym2->demangled_name))
+ continue;
+
+ sym1->twin = sym2;
+ sym2->twin = sym1;
+ break;
+ }
+ }
+
+ /* Correlate locals after the first FILE symbol */
+ for (; ; file1_sym = next_file_symbol(e->orig, file1_sym),
+ file2_sym = next_file_symbol(e->patched, file2_sym)) {
if (!file1_sym && file2_sym) {
ERROR("FILE symbol mismatch: NULL != %s", file2_sym->name);
^ permalink raw reply related
* Re: [PATCH 5/5] objtool/klp: provide friendlier error messages
From: Josh Poimboeuf @ 2026-01-31 0:37 UTC (permalink / raw)
To: Joe Lawrence; +Cc: live-patching, Jiri Kosina, Miroslav Benes, Petr Mladek
In-Reply-To: <20260130175950.1056961-6-joe.lawrence@redhat.com>
On Fri, Jan 30, 2026 at 12:59:50PM -0500, Joe Lawrence wrote:
> @@ -913,7 +914,7 @@ if (( SHORT_CIRCUIT <= 1 )); then
> validate_patches
> status "Building original kernel"
> clean_kernel
> - build_kernel
> + build_kernel "Original"
> status "Copying original object files"
> copy_orig_objects
> fi
> @@ -923,7 +924,7 @@ if (( SHORT_CIRCUIT <= 2 )); then
> fix_patches
> apply_patches
> status "Building patched kernel"
> - build_kernel
> + build_kernel "Patched"
nit: these should be lowercase for consistency with other error
messages:
error: klp-build: original kernel build failed
--
Josh
^ permalink raw reply
* Re: [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option
From: Josh Poimboeuf @ 2026-01-30 23:36 UTC (permalink / raw)
To: Song Liu
Cc: Joe Lawrence, live-patching, Jiri Kosina, Miroslav Benes,
Petr Mladek
In-Reply-To: <CAPhsuW6UwF+JAUGHpokSJ=sMJzhxZixdPZHznfdpdWioH2+Cwg@mail.gmail.com>
On Fri, Jan 30, 2026 at 03:20:22PM -0800, Song Liu wrote:
> On Fri, Jan 30, 2026 at 2:54 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > Something like this?
> >
> > if (( SHORT_CIRCUIT <= 2 )); then
> > status "Validating patch(es)"
> > validate_patches
> > fix_patches # including fixing fuzz???
> > fi
>
> I was thinking to change the above as
> if (( SHORT_CIRCUIT <= 0 ))
>
> Then we can save the fixed version of all the patches.
>
> But I think "SHORT_CIRCUIT <= 2" is cleaner, so this version is better.
Right. Just to clarify, the point of doing --short-circuit=2 (from my
experience) is you want to use a new .patch file which is different from
the one used by the previous klp-build incantation, but you don't want
to wait for the original build again. Putting that behind
"SHORT_CIRCUIT <= 0" would prevent the use of the new .patch file.
--
Josh
^ permalink raw reply
* Re: [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option
From: Josh Poimboeuf @ 2026-01-30 23:31 UTC (permalink / raw)
To: Joe Lawrence; +Cc: live-patching, Jiri Kosina, Miroslav Benes, Petr Mladek
In-Reply-To: <aX0Xe8ERVjPeu24j@redhat.com>
On Fri, Jan 30, 2026 at 03:41:31PM -0500, Joe Lawrence wrote:
> On Fri, Jan 30, 2026 at 12:09:35PM -0800, Josh Poimboeuf wrote:
> > On Fri, Jan 30, 2026 at 12:59:49PM -0500, Joe Lawrence wrote:
> > > @@ -131,6 +133,7 @@ Advanced Options:
> > > 3|diff Diff objects
> > > 4|kmod Build patch module
> > > -T, --keep-tmp Preserve tmp dir on exit
> > > + -z, --fuzz[=NUM] Rebase patches using fuzzy matching [default: 2]
> >
> > Ideally I think klp-build should accept a patch level fuzz of 2 by
> > default. If we just made that the default then maybe we don't need this
> > option?
> >
>
> Do you mean to drop the optional level value, or to just perform level-2
> fuzz rebasing as a matter of course (so no -z option altogether)?
Sorry, I was a bit confused by the previous patch. I was thinking "git
apply" already has a default fuzz level of 2, and that --recount made it
stricter somehow. But now I see that the "git apply" default is *no*
fuzz, as opposed to GNU patch which defaults to fuzz 2.
For kpatch-build we used GNU patch, should we just change klp-build to
use that as well? It worked well for 10+ years and the defaults were
fine. We could maybe use patchutils to fix up the line numbers/counts.
Then we presumably wouldn't need the --fuzz option as there would be
sane defaults already. I think some fuzz is acceptable, especially
since patch shows a warning message when it happens.
--
Josh
^ permalink raw reply
* Re: [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option
From: Song Liu @ 2026-01-30 23:20 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Joe Lawrence, live-patching, Jiri Kosina, Miroslav Benes,
Petr Mladek
In-Reply-To: <47mvnqxh6mc6twwmkrcfmmhnyo3ujsab6tkotvuf2jmsupveib@sf65ms5pp4de>
On Fri, Jan 30, 2026 at 2:54 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Fri, Jan 30, 2026 at 12:46:19PM -0800, Song Liu wrote:
> > On Fri, Jan 30, 2026 at 12:14 PM Joe Lawrence <joe.lawrence@redhat.com> wrote:
> > >
> > > On Fri, Jan 30, 2026 at 11:58:06AM -0800, Song Liu wrote:
> > > > On Fri, Jan 30, 2026 at 10:00 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
> > > > [...]
> > > > > @@ -807,6 +906,8 @@ build_patch_module() {
> > > > > process_args "$@"
> > > > > do_init
> > > > >
> > > > > +maybe_rebase_patches
> > > > > +
> > > > > if (( SHORT_CIRCUIT <= 1 )); then
> > > >
> > > > I think we should call maybe_rebase_patches within this
> > > > if condition.
> > > >
> > >
> > > Hi Song,
> > >
> > > Ah yeah I stumbled on this, probably overthinking it:
> > >
> > > - we want to validate rebased patches (when requested)
> > > - validate_patches() isn't really required for step 1 (building the
> > > original kernel) but ...
> > > - it's nice to check the patches before going off and building a full
> > > kernel
> > > - the patches are needed in step 2 (building the patched kernel) but ...
> > > - patch validation occurs in step 1
> >
> > Hmm.. I see your point now.
> >
> > > so given the way the short circuiting works, I didn't see a good way to
> > > fold it in there. The user might want to jump right to building the
> > > patched kernel with patch rebasing. Maybe that's not valid thinking if
> > > the rebase occurs in step 1 and they are left behind in klp-tmp/ (so
> > > jumping to step 2 will just use the patches in the scratch dir and not
> > > command line?). It's Friday, maybe I'm missing something obvious? :)
> >
> > Maybe we should add another SHORT_CIRCUIT level for the validate
> > and rebase step? It could be step 0, or we can shift all existing steps.
>
> I don't see how that solves the problem? For --short-circuit=1 and
> --short-circuit=2 we still want to validate and rebase the patches
> because they are used in step 2. But as Joe mentioned, that can be done
> before step 1 to catch any patch errors quickly.
>
> Something like this?
>
> if (( SHORT_CIRCUIT <= 2 )); then
> status "Validating patch(es)"
> validate_patches
> fix_patches # including fixing fuzz???
> fi
I was thinking to change the above as
if (( SHORT_CIRCUIT <= 0 ))
Then we can save the fixed version of all the patches.
But I think "SHORT_CIRCUIT <= 2" is cleaner, so this version is better.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH 3/5] objtool/klp: validate patches with git apply --recount
From: Josh Poimboeuf @ 2026-01-30 23:02 UTC (permalink / raw)
To: Joe Lawrence; +Cc: live-patching, Jiri Kosina, Miroslav Benes, Petr Mladek
In-Reply-To: <omt3bm5upud3sywupr3g3evxqs437x5f5wcxlnba2j5u4rtle2@b62zb4hfydby>
On Fri, Jan 30, 2026 at 02:59:53PM -0800, Josh Poimboeuf wrote:
> On Fri, Jan 30, 2026 at 03:38:40PM -0500, Joe Lawrence wrote:
> > On Fri, Jan 30, 2026 at 12:05:35PM -0800, Josh Poimboeuf wrote:
> > > Hm, isn't the whole point of --recount that it ignores the line numbers?
> > > Or does it just ignore the numbers after the commas (the counts)?
> > >
> >
> > I don't know exactly. As I continue digging into the test that sent me
> > down this path, I just found that `git apply --recount` doesn't like
> > some output generated by `combinediff -q --combine` even with NO line
> > drift... then if I manually added in corresponding diff command lines
> > (to make it look more like a .patch file generated by `diff -Nu`), ie:
> >
> > diff -Nu src.orig/fs/proc/array.c src/fs/proc/array.c <---
> > --- src.orig/fs/proc/array.c
> > +++ src/fs/proc/array.c
> >
> > Suddenly `git apply --recount` is happy with the patch.
> >
> > So I suspect that I started with git not liking the hunks generated by
> > combinediff and drove it to the rebase feature, which solves a more
> > interesting problem, but by side effect smoothed over this format
> > issue when it recreated the patch with git.
> >
> > Anyway, I think this patch still stands on it's own: perform the same
> > apply/revert check as what would happen in the fixup steps to fail
> > faster for the user?
>
> If we just run fix_patches() at the beginning then can we just get rid
> of validate_patches() altogether?
Or at least validate_patches() could be replaced with
check_unsupported_patches(), as the apply/revert test wouldn't be needed
since the actual apply/revert would happen immediately after that in
fix_patches().
--
Josh
^ permalink raw reply
* Re: [PATCH 3/5] objtool/klp: validate patches with git apply --recount
From: Josh Poimboeuf @ 2026-01-30 22:59 UTC (permalink / raw)
To: Joe Lawrence; +Cc: live-patching, Jiri Kosina, Miroslav Benes, Petr Mladek
In-Reply-To: <aX0W0JWRkLbuQpGY@redhat.com>
On Fri, Jan 30, 2026 at 03:38:40PM -0500, Joe Lawrence wrote:
> On Fri, Jan 30, 2026 at 12:05:35PM -0800, Josh Poimboeuf wrote:
> > Hm, isn't the whole point of --recount that it ignores the line numbers?
> > Or does it just ignore the numbers after the commas (the counts)?
> >
>
> I don't know exactly. As I continue digging into the test that sent me
> down this path, I just found that `git apply --recount` doesn't like
> some output generated by `combinediff -q --combine` even with NO line
> drift... then if I manually added in corresponding diff command lines
> (to make it look more like a .patch file generated by `diff -Nu`), ie:
>
> diff -Nu src.orig/fs/proc/array.c src/fs/proc/array.c <---
> --- src.orig/fs/proc/array.c
> +++ src/fs/proc/array.c
>
> Suddenly `git apply --recount` is happy with the patch.
>
> So I suspect that I started with git not liking the hunks generated by
> combinediff and drove it to the rebase feature, which solves a more
> interesting problem, but by side effect smoothed over this format
> issue when it recreated the patch with git.
>
> Anyway, I think this patch still stands on it's own: perform the same
> apply/revert check as what would happen in the fixup steps to fail
> faster for the user?
If we just run fix_patches() at the beginning then can we just get rid
of validate_patches() altogether?
--
Josh
^ permalink raw reply
* Re: [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option
From: Josh Poimboeuf @ 2026-01-30 22:54 UTC (permalink / raw)
To: Song Liu
Cc: Joe Lawrence, live-patching, Jiri Kosina, Miroslav Benes,
Petr Mladek
In-Reply-To: <CAPhsuW60Gqht9QUEvW1PyMOORM=oWrWiJmfFF8Q+aEgX0DqQXQ@mail.gmail.com>
On Fri, Jan 30, 2026 at 12:46:19PM -0800, Song Liu wrote:
> On Fri, Jan 30, 2026 at 12:14 PM Joe Lawrence <joe.lawrence@redhat.com> wrote:
> >
> > On Fri, Jan 30, 2026 at 11:58:06AM -0800, Song Liu wrote:
> > > On Fri, Jan 30, 2026 at 10:00 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
> > > [...]
> > > > @@ -807,6 +906,8 @@ build_patch_module() {
> > > > process_args "$@"
> > > > do_init
> > > >
> > > > +maybe_rebase_patches
> > > > +
> > > > if (( SHORT_CIRCUIT <= 1 )); then
> > >
> > > I think we should call maybe_rebase_patches within this
> > > if condition.
> > >
> >
> > Hi Song,
> >
> > Ah yeah I stumbled on this, probably overthinking it:
> >
> > - we want to validate rebased patches (when requested)
> > - validate_patches() isn't really required for step 1 (building the
> > original kernel) but ...
> > - it's nice to check the patches before going off and building a full
> > kernel
> > - the patches are needed in step 2 (building the patched kernel) but ...
> > - patch validation occurs in step 1
>
> Hmm.. I see your point now.
>
> > so given the way the short circuiting works, I didn't see a good way to
> > fold it in there. The user might want to jump right to building the
> > patched kernel with patch rebasing. Maybe that's not valid thinking if
> > the rebase occurs in step 1 and they are left behind in klp-tmp/ (so
> > jumping to step 2 will just use the patches in the scratch dir and not
> > command line?). It's Friday, maybe I'm missing something obvious? :)
>
> Maybe we should add another SHORT_CIRCUIT level for the validate
> and rebase step? It could be step 0, or we can shift all existing steps.
I don't see how that solves the problem? For --short-circuit=1 and
--short-circuit=2 we still want to validate and rebase the patches
because they are used in step 2. But as Joe mentioned, that can be done
before step 1 to catch any patch errors quickly.
Something like this?
if (( SHORT_CIRCUIT <= 2 )); then
status "Validating patch(es)"
validate_patches
fix_patches # including fixing fuzz???
fi
if (( SHORT_CIRCUIT <= 1 )); then
status "Building original kernel"
clean_kernel
build_kernel "Original"
status "Copying original object files"
copy_orig_objects
fi
if (( SHORT_CIRCUIT <= 2 )); then
status "Building patched kernel"
apply_patches
build_kernel "Patched"
...
fi
--
Josh
^ permalink raw reply
* Re: [PATCH v3 0/2] Improve handling of the __klp_{objects,funcs} sections in modules
From: Josh Poimboeuf @ 2026-01-30 21:27 UTC (permalink / raw)
To: Petr Pavlu
Cc: Jiri Kosina, Miroslav Benes, Petr Mladek, Joe Lawrence,
Luis Chamberlain, Daniel Gomez, Sami Tolvanen, Aaron Tomlin,
Peter Zijlstra, live-patching, linux-modules, linux-kernel
In-Reply-To: <20260123102825.3521961-1-petr.pavlu@suse.com>
On Fri, Jan 23, 2026 at 11:26:55AM +0100, Petr Pavlu wrote:
> Changes since v2 [1]:
> - Generalize the helper function that locates __klp_objects in a module
> to allow it to find any data in other sections as well.
>
> Changes since v1 [2]:
> - Generalize the helper function that locates __klp_objects in a module
> to allow it to find objects in other sections as well.
>
> [1] https://lore.kernel.org/linux-modules/20260121082842.3050453-1-petr.pavlu@suse.com/
> [2] https://lore.kernel.org/linux-modules/20260114123056.2045816-1-petr.pavlu@suse.com/
>
> Petr Pavlu (2):
> livepatch: Fix having __klp_objects relics in non-livepatch modules
> livepatch: Free klp_{object,func}_ext data after initialization
If there are no objections, I will go ahead and queue these patches up
in -tip.
--
Josh
^ permalink raw reply
* Re: [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option
From: Song Liu @ 2026-01-30 20:46 UTC (permalink / raw)
To: Joe Lawrence
Cc: live-patching, Josh Poimboeuf, Jiri Kosina, Miroslav Benes,
Petr Mladek
In-Reply-To: <aX0RBzV5X1lgQ2ec@redhat.com>
On Fri, Jan 30, 2026 at 12:14 PM Joe Lawrence <joe.lawrence@redhat.com> wrote:
>
> On Fri, Jan 30, 2026 at 11:58:06AM -0800, Song Liu wrote:
> > On Fri, Jan 30, 2026 at 10:00 AM Joe Lawrence <joe.lawrence@redhat.com> wrote:
> > [...]
> > > @@ -807,6 +906,8 @@ build_patch_module() {
> > > process_args "$@"
> > > do_init
> > >
> > > +maybe_rebase_patches
> > > +
> > > if (( SHORT_CIRCUIT <= 1 )); then
> >
> > I think we should call maybe_rebase_patches within this
> > if condition.
> >
>
> Hi Song,
>
> Ah yeah I stumbled on this, probably overthinking it:
>
> - we want to validate rebased patches (when requested)
> - validate_patches() isn't really required for step 1 (building the
> original kernel) but ...
> - it's nice to check the patches before going off and building a full
> kernel
> - the patches are needed in step 2 (building the patched kernel) but ...
> - patch validation occurs in step 1
Hmm.. I see your point now.
> so given the way the short circuiting works, I didn't see a good way to
> fold it in there. The user might want to jump right to building the
> patched kernel with patch rebasing. Maybe that's not valid thinking if
> the rebase occurs in step 1 and they are left behind in klp-tmp/ (so
> jumping to step 2 will just use the patches in the scratch dir and not
> command line?). It's Friday, maybe I'm missing something obvious? :)
Maybe we should add another SHORT_CIRCUIT level for the validate
and rebase step? It could be step 0, or we can shift all existing steps.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH v3 0/2] Improve handling of the __klp_{objects,funcs} sections in modules
From: Aaron Tomlin @ 2026-01-30 20:46 UTC (permalink / raw)
To: Petr Pavlu
Cc: Josh Poimboeuf, Jiri Kosina, Miroslav Benes, Petr Mladek,
Joe Lawrence, Luis Chamberlain, Daniel Gomez, Sami Tolvanen,
Peter Zijlstra, live-patching, linux-modules, linux-kernel
In-Reply-To: <20260123102825.3521961-1-petr.pavlu@suse.com>
[-- Attachment #1: Type: text/plain, Size: 1341 bytes --]
On Fri, Jan 23, 2026 at 11:26:55AM +0100, Petr Pavlu wrote:
> Changes since v2 [1]:
> - Generalize the helper function that locates __klp_objects in a module
> to allow it to find any data in other sections as well.
>
> Changes since v1 [2]:
> - Generalize the helper function that locates __klp_objects in a module
> to allow it to find objects in other sections as well.
>
> [1] https://lore.kernel.org/linux-modules/20260121082842.3050453-1-petr.pavlu@suse.com/
> [2] https://lore.kernel.org/linux-modules/20260114123056.2045816-1-petr.pavlu@suse.com/
>
> Petr Pavlu (2):
> livepatch: Fix having __klp_objects relics in non-livepatch modules
> livepatch: Free klp_{object,func}_ext data after initialization
>
> include/linux/livepatch.h | 3 +++
> kernel/livepatch/core.c | 19 +++++++++++++++++++
> scripts/livepatch/init.c | 20 +++++++++-----------
> scripts/module.lds.S | 9 ++-------
> tools/objtool/check.c | 2 +-
> tools/objtool/include/objtool/klp.h | 10 +++++-----
> tools/objtool/klp-diff.c | 2 +-
> 7 files changed, 40 insertions(+), 25 deletions(-)
>
>
> base-commit: 0f61b1860cc3f52aef9036d7235ed1f017632193
> --
> 2.52.0
>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
--
Aaron Tomlin
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 4/5] objtool/klp: add -z/--fuzz patch rebasing option
From: Joe Lawrence @ 2026-01-30 20:41 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: live-patching, Jiri Kosina, Miroslav Benes, Petr Mladek
In-Reply-To: <fayrtgx5l5wvcwkuxqc4it3t4ft3o7rbn4uojtmzjxq66nniw7@v6om4zyepshh>
On Fri, Jan 30, 2026 at 12:09:35PM -0800, Josh Poimboeuf wrote:
> On Fri, Jan 30, 2026 at 12:59:49PM -0500, Joe Lawrence wrote:
> > @@ -131,6 +133,7 @@ Advanced Options:
> > 3|diff Diff objects
> > 4|kmod Build patch module
> > -T, --keep-tmp Preserve tmp dir on exit
> > + -z, --fuzz[=NUM] Rebase patches using fuzzy matching [default: 2]
>
> Ideally I think klp-build should accept a patch level fuzz of 2 by
> default. If we just made that the default then maybe we don't need this
> option?
>
Do you mean to drop the optional level value, or to just perform level-2
fuzz rebasing as a matter of course (so no -z option altogether)?
--
Joe
^ permalink raw reply
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