* Re: [PATCH v2] livepatch: Match old_sympos 0 and 1 in klp_find_func()
From: Petr Mladek @ 2025-10-15 13:10 UTC (permalink / raw)
To: Song Liu
Cc: live-patching, jpoimboe, jikos, mbenes, joe.lawrence, kernel-team
In-Reply-To: <20251013173019.990707-1-song@kernel.org>
On Mon 2025-10-13 10:30:19, Song Liu wrote:
> When there is only one function of the same name, old_sympos of 0 and 1
> are logically identical. Match them in klp_find_func().
>
> This is to avoid a corner case with different toolchain behavior.
>
> In this specific issue, issue two versions of kpatch-build were used to
s/issue, issue/issue/
> build livepatch for the same kernel. One assigns old_sympos == 0 for
> unique local functions, the other assigns old_sympos == 1 for unique
> local functions. Both versions work fine by themselves. (PS: This
> behavior change was introduced in a downstream version of kpatch-build.
> This change does not exist in upstream kpatch-build.)
>
> However, during livepatch upgrade (with the replace flag set) from a
> patch built with one version of kpatch-build to the same fix built with
> the other version of kpatch-build, livepatching fails with errors like:
>
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -88,8 +88,14 @@ static struct klp_func *klp_find_func(struct klp_object *obj,
> struct klp_func *func;
>
> klp_for_each_func(obj, func) {
> + /*
> + * Besides identical old_sympos, also condiser old_sympos
As Josh already pointed out:
s/condiser/consider/
> + * of 0 and 1 are identical.
> + */
> if ((strcmp(old_func->old_name, func->old_name) == 0) &&
> - (old_func->old_sympos == func->old_sympos)) {
> + ((old_func->old_sympos == func->old_sympos) ||
> + (old_func->old_sympos == 0 && func->old_sympos == 1) ||
> + (old_func->old_sympos == 1 && func->old_sympos == 0))) {
> return func;
> }
> }
With the two above fixes:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Tested-by: Petr Mladek <pmladek@suse.com>
I have fixed both problems when committing.
And the patch has been committed into livepatching.git,
branch for-6.19/trivial.
Best Regards,
Petr
^ permalink raw reply
* Re: Question - Livepatch/Kprobe Coexistence on Ftrace-enabled Functions (Ubuntu kernel based on Linux stable 5.15.30)
From: Petr Mladek @ 2025-10-15 11:53 UTC (permalink / raw)
To: Andrey Grodzovsky
Cc: kernel-team@lists.ubuntu.com, live-patching@vger.kernel.org
In-Reply-To: <c5058315a39d4615b333e485893345be@crowdstrike.com>
On Tue 2025-10-14 21:37:49, Andrey Grodzovsky wrote:
> Dear Upstream Livepatch team and Ubuntu Kernel team - I included you both in this since the issue lies on the boundary between Ubuntu kernel and upstream.
>
> According to official kernel documentation - https://docs.kernel.org/livepatch/livepatch.html#livepatch, section 7, Limitations -
> 1 - Kretprobes using the ftrace framework conflict with the patched functions.
> 2 - Kprobes in the original function are ignored when the code is redirected to the new implementation.
>
> Yet, when testing on my Ubuntu 5.15.0-1005.7-aws (based on 5.15.30 stable kernel) machine, I have no problem applying Livepatch and then setting krpobes and kretprobes on a patched function using bpftrace (or directly by coding a BPF program with kprobe/kretprobe attachment)and can confirm both execute without issues. Also the opposite works fine, running my krpobe and kretprobe hooks doesn't prevent from livepatch to be applied successfully.
>
> fentry/fexit probes do fail in in both directions - but this is expected according to my understanding as coexistence of livepatching and ftrace based BPF hooks are mutually exclusive until 6.0 based kernels
>
> libbpf: prog 'begin_new_exec_fentry': failed to attach: Device or resource busy
> libbpf: prog 'begin_new_exec_fentry': failed to auto-attach: -16
>
>
> Please help me understand this contradiction about kprobes - is this because the KPROBES are FTRACE based or any other reason ?
Heh, it seems that we have discussed this 10 years ago and I already
forgot most details.
Yes, the conflict is detected when KPROBES are using FTRACE
infrastructure. But it happens only when the KPROBE needs to redirect
the function call, namely when it needs to modify IP address which will be used
when all attached ftrace callbacks are proceed.
It is related to the FTRACE_OPS_FL_IPMODIFY flag.
More details can be found in the discussion at
https://lore.kernel.org/all/20141121102516.11844.27829.stgit@localhost.localdomain/T/#re746846b6b16c49a55c89b4c63b7995fe5972111
I seems that I made some analyze when it worked and it did not work,
see https://lore.kernel.org/all/20141121102516.11844.27829.stgit@localhost.localdomain/T/#mffd8c8bf4325b473d89876f2805f42f1af7c82d7
But I am not 100% sure that it was correct. Also it was before the
BPF-boom.
Also you might look at the selftest in the todays Linus' tree:
+ tools/testing/selftests/livepatch/test-kprobe.sh
+ tools/testing/selftests/livepatch/test_modules/test_klp_kprobe.c
+ tools/testing/selftests/livepatch/test_modules/test_klp_livepatch.c
The parallel load fails when the Kprobe is using a post_handler.
Sigh, we should fix the livepatch documentation. The kretprobes
obviously work. register_kretprobe() even explicitely sets:
rp->kp.post_handler = NULL;
It seems that .post_handler is called after all ftrace handlers.
And it sets IP after the NOPs, see kprobe_ftrace_handler().
I am not sure about the use case.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH] powerpc64/bpf: support direct_call on livepatch function
From: Naveen N Rao @ 2025-10-15 6:18 UTC (permalink / raw)
To: Hari Bathini
Cc: Madhavan Srinivasan, linuxppc-dev, Christophe Leroy,
Michael Ellerman, Nicholas Piggin, bpf, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Song Liu, Jiri Olsa,
Viktor Malik, live-patching, Josh Poimboeuf, Joe Lawrence,
Jiri Kosina, linux-trace-kernel, Steven Rostedt, Masami Hiramatsu,
Mark Rutland, Shung-Hsi Yu
In-Reply-To: <79946463-4742-4919-9d56-927a0a6f1c7c@linux.ibm.com>
On Fri, Oct 10, 2025 at 12:47:21PM +0530, Hari Bathini wrote:
>
>
> On 09/10/25 4:57 pm, Naveen N Rao wrote:
> > On Thu, Oct 09, 2025 at 11:19:45AM +0530, Hari Bathini wrote:
> > >
> > >
> > > On 08/10/25 1:43 pm, Naveen N Rao wrote:
> > > > On Mon, Oct 06, 2025 at 06:50:20PM +0530, Hari Bathini wrote:
> > > > >
> > > > >
> > > > > On 06/10/25 1:22 pm, Naveen N Rao wrote:
> > > > > > On Fri, Oct 03, 2025 at 12:57:54AM +0530, Hari Bathini wrote:
> > > > > > > Today, livepatch takes precedence over direct_call. Instead, save the
> > > > > > > state and make direct_call before handling livepatch.
> > > > > >
> > > > > > If we call into the BPF trampoline first and if we have
> > > > > > BPF_TRAMP_F_CALL_ORIG set, does this result in the BPF trampoline
> > > > > > calling the new copy of the live-patched function or the old one?
> > > > >
> > > > > Naveen, calls the new copy of the live-patched function..
> > > >
> > > > Hmm... I'm probably missing something.
> > > >
> > > > With ftrace OOL stubs, what I recall is that BPF trampoline derives the
> > > > original function address from the OOL stub (which would be associated
> > > > with the original function, not the livepatch one).
> > >
> > > Trampoline derives the address from LR.
> >
> > Does it? I'm referring to BPF_TRAMP_F_CALL_ORIG handling in
> > __arch_prepare_bpf_trampoline().
>
>
> > LR at BPF trampoline entry points at
> > the ftrace OOL stub. We recover the "real LR" pointing to the function
> > being traced from there so that we can call into it from within the BPF
> > trampoline.
>
> Naveen, from the snippet in livepatch_handler code shared below,
> the LR at BPF trmapoline entry points at the 'nop' after the call
> to trampoline with 'bnectrl cr1' in the updated livepatch_handler.
>
> Mimic'ing ftrace OOL branch instruction in livepatch_handler
> with 'b 1f' (the instruction after nop) to ensure the trmapoline
> derives the real LR to '1f' and jumps back into the livepatch_handler..
>
> + /* Jump to the direct_call */
> + bnectrl cr1
> +
> + /*
> + * The address to jump after direct call is deduced based on ftrace
> OOL stub sequence.
> + * The seemingly insignificant couple of instructions below is to
> mimic that here to
> + * jump back to the livepatch handler code below.
> + */
> + nop
> + b 1f
> +
> + /*
> + * Restore the state for livepatching from the livepatch stack.
> + * Before that, check if livepatch stack is intact. Use r0 for it.
> + */
> +1: mtctr r0
Ah, so you are faking a ftrace OOL stub here. But, won't this mean that
bpf_get_func_ip() won't return the function address anymore?
One of the other thoughts I had was if we could stuff the function
address into the ftrace OOL stub. I had considered this back when I
implemented the OOL stubs, but didn't do it due to the extra memory
requirement. However, given the dance we're having to do, I'm now
thinking that may make sense and can simplify the code. If we can also
hook into livepatch, then we should be able to update the function
address in the stub to point to the new address and the trampoline
should then "just work" since it already saves/restores the TOC [We may
additionally have to update the function IP in _R12, but that would be a
minor change overall]
We will still need a way to restore livepatch TOC if the BPF trampoline
doesn't itself call into the function, but we may be able to handle that
if we change the return address to jump to a stub that restores the TOC
from the livepatch stack.
>
>
> I should probably improve my comments for better readability..
Yes, please. I would also split the changes converting some of the hard
coded offsets into macros into a separate patch.
- Naveen
^ permalink raw reply
* Question - Livepatch/Kprobe Coexistence on Ftrace-enabled Functions (Ubuntu kernel based on Linux stable 5.15.30)
From: Andrey Grodzovsky @ 2025-10-14 21:37 UTC (permalink / raw)
To: kernel-team@lists.ubuntu.com, live-patching@vger.kernel.org
Dear Upstream Livepatch team and Ubuntu Kernel team - I included you both in this since the issue lies on the boundary between Ubuntu kernel and upstream.
According to official kernel documentation - https://docs.kernel.org/livepatch/livepatch.html#livepatch, section 7, Limitations -
1 - Kretprobes using the ftrace framework conflict with the patched functions.
2 - Kprobes in the original function are ignored when the code is redirected to the new implementation.
Yet, when testing on my Ubuntu 5.15.0-1005.7-aws (based on 5.15.30 stable kernel) machine, I have no problem applying Livepatch and then setting krpobes and kretprobes on a patched function using bpftrace (or directly by coding a BPF program with kprobe/kretprobe attachment)and can confirm both execute without issues. Also the opposite works fine, running my krpobe and kretprobe hooks doesn't prevent from livepatch to be applied successfully.
fentry/fexit probes do fail in in both directions - but this is expected according to my understanding as coexistence of livepatching and ftrace based BPF hooks are mutually exclusive until 6.0 based kernels
libbpf: prog 'begin_new_exec_fentry': failed to attach: Device or resource busy
libbpf: prog 'begin_new_exec_fentry': failed to auto-attach: -16
Please help me understand this contradiction about kprobes - is this because the KPROBES are FTRACE based or any other reason ?
Bellow a few prints to prove my point - the kernel function i am using to test is begin_new_exec
ubuntu@ip-xxxxx:~$ sudo canonical-livepatch status
last check: 19 minutes ago
kernel: 5.15.0-1005.7-aws
server check-in: succeeded
kernel state: ✗ Livepatch coverage ended 2023-05-20; please upgrade the kernel and reboot
patch state: ✓ all applicable livepatch modules inserted
patch version: 94.1
tier: stable
machine id: xxxxx
ubuntu@ip-xxxxxx:~$ sudo cat /proc/kallsyms | grep begin_new_exec
ffffffff8af7bdc0 T begin_new_exec
ffffffff8c335694 r __ksymtab_begin_new_exec
ffffffff8c369830 r __kstrtabns_begin_new_exec
ffffffff8c36cf3d r __kstrtab_begin_new_exec
ffffffffc28c1650 t begin_new_exec [lkp_Ubuntu_5_15_0_1005_7_aws_94]
ffffffffc1a9d388 t bpf_prog_211a1dc71de113a4_begin_new_exec_kprobe [bpf]
ffffffffc1a9f588 t bpf_prog_5522bacfbb7628bd_begin_new_exec_kretprobe [bpf]
ubuntu@ip-xxxxx:~$ sudo cat /sys/kernel/debug/kprobes/list | grep begin_new_exec
ffffffff8af7bdc0 r begin_new_exec+0x0 [FTRACE]
ffffffff8af7bdc0 k begin_new_exec+0x0 [FTRACE]
root@ip-xxxxx:~# echo 102400 > /sys/kernel/debug/tracing/buffer_size_kb && echo 1 > /sys/kernel/debug/tracing/events/bpf_trace/enable && echo 1 > /sys/kernel/debug/tracing/tracing_on && cat
/sys/kernel/debug/tracing/trace_pipe
cat-10406 [000] d...1 433341.003035: bpf_trace_printk: kprobe: begin_new_exec called with bprm=000000005304a36e
cat-10406 [000] d...1 433341.003163: bpf_trace_printk: kretprobe: begin_new_exec returned 0
^ permalink raw reply
* Re: [PATCH v2] livepatch: Match old_sympos 0 and 1 in klp_find_func()
From: Josh Poimboeuf @ 2025-10-14 16:58 UTC (permalink / raw)
To: Song Liu; +Cc: live-patching, jikos, mbenes, pmladek, joe.lawrence, kernel-team
In-Reply-To: <20251013173019.990707-1-song@kernel.org>
On Mon, Oct 13, 2025 at 10:30:19AM -0700, Song Liu wrote:
> +++ b/kernel/livepatch/core.c
> @@ -88,8 +88,14 @@ static struct klp_func *klp_find_func(struct klp_object *obj,
> struct klp_func *func;
>
> klp_for_each_func(obj, func) {
> + /*
> + * Besides identical old_sympos, also condiser old_sympos
> + * of 0 and 1 are identical.
"consider"
Otherwise, seems fine...
Acked-by: Josh Poimboeuf <jpoimboe@kernel.org>
--
Josh
^ permalink raw reply
* [PATCH v2] livepatch: Match old_sympos 0 and 1 in klp_find_func()
From: Song Liu @ 2025-10-13 17:30 UTC (permalink / raw)
To: live-patching
Cc: jpoimboe, jikos, mbenes, pmladek, joe.lawrence, kernel-team,
Song Liu
When there is only one function of the same name, old_sympos of 0 and 1
are logically identical. Match them in klp_find_func().
This is to avoid a corner case with different toolchain behavior.
In this specific issue, issue two versions of kpatch-build were used to
build livepatch for the same kernel. One assigns old_sympos == 0 for
unique local functions, the other assigns old_sympos == 1 for unique
local functions. Both versions work fine by themselves. (PS: This
behavior change was introduced in a downstream version of kpatch-build.
This change does not exist in upstream kpatch-build.)
However, during livepatch upgrade (with the replace flag set) from a
patch built with one version of kpatch-build to the same fix built with
the other version of kpatch-build, livepatching fails with errors like:
[ 14.218706] sysfs: cannot create duplicate filename 'xxx/somefunc,1'
...
[ 14.219466] Call Trace:
[ 14.219468] <TASK>
[ 14.219469] dump_stack_lvl+0x47/0x60
[ 14.219474] sysfs_warn_dup.cold+0x17/0x27
[ 14.219476] sysfs_create_dir_ns+0x95/0xb0
[ 14.219479] kobject_add_internal+0x9e/0x260
[ 14.219483] kobject_add+0x68/0x80
[ 14.219485] ? kstrdup+0x3c/0xa0
[ 14.219486] klp_enable_patch+0x320/0x830
[ 14.219488] patch_init+0x443/0x1000 [ccc_0_6]
[ 14.219491] ? 0xffffffffa05eb000
[ 14.219492] do_one_initcall+0x2e/0x190
[ 14.219494] do_init_module+0x67/0x270
[ 14.219496] init_module_from_file+0x75/0xa0
[ 14.219499] idempotent_init_module+0x15a/0x240
[ 14.219501] __x64_sys_finit_module+0x61/0xc0
[ 14.219503] do_syscall_64+0x5b/0x160
[ 14.219505] entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 14.219507] RIP: 0033:0x7f545a4bd96d
...
[ 14.219516] kobject: kobject_add_internal failed for somefunc,1 with
-EEXIST, don't try to register things with the same name ...
This happens because klp_find_func() thinks somefunc with old_sympos==0
is not the same as somefunc with old_sympos==1, and klp_add_object_nops
adds another xxx/func,1 to the list of functions to patch.
Signed-off-by: Song Liu <song@kernel.org>
---
kernel/livepatch/core.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 0e73fac55f8e..53c3b9b40c8b 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -88,8 +88,14 @@ static struct klp_func *klp_find_func(struct klp_object *obj,
struct klp_func *func;
klp_for_each_func(obj, func) {
+ /*
+ * Besides identical old_sympos, also condiser old_sympos
+ * of 0 and 1 are identical.
+ */
if ((strcmp(old_func->old_name, func->old_name) == 0) &&
- (old_func->old_sympos == func->old_sympos)) {
+ ((old_func->old_sympos == func->old_sympos) ||
+ (old_func->old_sympos == 0 && func->old_sympos == 1) ||
+ (old_func->old_sympos == 1 && func->old_sympos == 0))) {
return func;
}
}
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] livepatch: Match old_sympos 0 and 1 in klp_find_func()
From: Petr Mladek @ 2025-10-13 14:45 UTC (permalink / raw)
To: Song Liu
Cc: live-patching, jpoimboe, jikos, mbenes, joe.lawrence, kernel-team
In-Reply-To: <20251010230223.4013896-1-song@kernel.org>
On Fri 2025-10-10 16:02:23, Song Liu wrote:
> When there is only one function of the same name, old_sympos of 0 and 1
> are logically identical. Match them in klp_find_func().
>
> Signed-off-by: Song Liu <song@kernel.org>
>
> ---
I would prefer to add the details into the commit message.
It would make it clear that it was a real life problem.
Also it explains the effects.
It would just need to convert the text into the imperative
style, like:
There are two versions of kpatch-build, ...
Even better would be to mention which version introduced the change.
But it is not strictly necessary.
> This is to avoid a corner case I hit in testing.
>
> I had two versions of kpatch-build, one assigns old_sympos == 0 for
> unique local functions, the other assigns old_sympos == 1 for unique
> local functions. Both versions work fine by themselves.
>
> However, when we do patch upgrade (with the replace flag) with a
Imperative language:
During the patch upgrade (with the replace ...
> patch built with one version of kpatch-build to replace the same fix
> bult with the other version of kpatch-build, we hit errors like:
>
> [ 14.218706] sysfs: cannot create duplicate filename 'xxx/somefunc,1'
> ...
> [ 14.219466] Call Trace:
> [ 14.219468] <TASK>
> [ 14.219469] dump_stack_lvl+0x47/0x60
> [ 14.219474] sysfs_warn_dup.cold+0x17/0x27
> [ 14.219476] sysfs_create_dir_ns+0x95/0xb0
> [ 14.219479] kobject_add_internal+0x9e/0x260
> [ 14.219483] kobject_add+0x68/0x80
> [ 14.219485] ? kstrdup+0x3c/0xa0
> [ 14.219486] klp_enable_patch+0x320/0x830
> [ 14.219488] patch_init+0x443/0x1000 [ccc_0_6]
> [ 14.219491] ? 0xffffffffa05eb000
> [ 14.219492] do_one_initcall+0x2e/0x190
> [ 14.219494] do_init_module+0x67/0x270
> [ 14.219496] init_module_from_file+0x75/0xa0
> [ 14.219499] idempotent_init_module+0x15a/0x240
> [ 14.219501] __x64_sys_finit_module+0x61/0xc0
> [ 14.219503] do_syscall_64+0x5b/0x160
> [ 14.219505] entry_SYSCALL_64_after_hwframe+0x4b/0x53
> [ 14.219507] RIP: 0033:0x7f545a4bd96d
> ...
> [ 14.219516] kobject: kobject_add_internal failed for somefunc,1 with
> -EEXIST, don't try to register things with the same name ...
>
> This happens because klp_find_func() thinks somefunc with old_sympos==0
> is not the same as somefunc with old_sympos==1, and klp_add_object_nops
> adds another xxx/func,1 to the list of functions to patch.
>
> Yes, this is a really rare case, and the toolchain (kpatch-build) should
> be consistent with old_sympos. But I think we may want to fix the
> behavior in kernel just in case.
The last paragraph should not be in the comment.
Otherwise, I think that the change is worth it. As you say,
it is a rare case. But it clearly might happen. And the change
makes the livepatching code more robust.
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH] selftests: livepatch: use canonical ftrace path
From: Petr Mladek @ 2025-10-13 14:28 UTC (permalink / raw)
To: Fushuai Wang
Cc: jpoimboe, jikos, mbenes, joe.lawrence, shuah, live-patching,
linux-kselftest, linux-kernel
In-Reply-To: <20251010120727.20631-1-wangfushuai@baidu.com>
On Fri 2025-10-10 20:07:27, Fushuai Wang wrote:
> Since v4.1 kernel, a new interface for ftrace called "tracefs" was
> introduced, which is usually mounted in /sys/kernel/tracing. Therefore,
> tracing files can now be accessed via either the legacy path
> /sys/kernel/debug/tracing or the newer path /sys/kernel/tracing.
>
> Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
Looks good to me:
Reviewed-by: Petr Mladek <pmladek@suse.com>
Tested-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH v4 00/63] objtool,livepatch: klp-build livepatch module generation
From: Josh Poimboeuf @ 2025-10-11 0:54 UTC (permalink / raw)
To: Petr Mladek
Cc: x86, linux-kernel, Miroslav Benes, Joe Lawrence, live-patching,
Song Liu, laokz, Jiri Kosina, Marcos Paulo de Souza, Weinan Liu,
Fazla Mehrab, Chen Zhongjin, Puranjay Mohan, Dylan Hatch,
Peter Zijlstra
In-Reply-To: <aOi2E_8k9G1EnDzG@pathway.suse.cz>
On Fri, Oct 10, 2025 at 09:30:27AM +0200, Petr Mladek wrote:
> On Wed 2025-09-17 09:03:08, Josh Poimboeuf wrote:
> > This series introduces new objtool features and a klp-build script to
> > generate livepatch modules using a source .patch as input.
> >
> > This builds on concepts from the longstanding out-of-tree kpatch [1]
> > project which began in 2012 and has been used for many years to generate
> > livepatch modules for production kernels. However, this is a complete
> > rewrite which incorporates hard-earned lessons from 12+ years of
> > maintaining kpatch.
>
> The series seems to be in a pretty good state, ready for linux-next, ...
>
> Acked-by: Petr Mladek <pmladek@suse.com>
Thanks! I'll queue these up for -tip.
--
Josh
^ permalink raw reply
* [PATCH] livepatch: Match old_sympos 0 and 1 in klp_find_func()
From: Song Liu @ 2025-10-10 23:02 UTC (permalink / raw)
To: live-patching
Cc: jpoimboe, jikos, mbenes, pmladek, joe.lawrence, kernel-team,
Song Liu
When there is only one function of the same name, old_sympos of 0 and 1
are logically identical. Match them in klp_find_func().
Signed-off-by: Song Liu <song@kernel.org>
---
This is to avoid a corner case I hit in testing.
I had two versions of kpatch-build, one assigns old_sympos == 0 for
unique local functions, the other assigns old_sympos == 1 for unique
local functions. Both versions work fine by themselves.
However, when we do patch upgrade (with the replace flag) with a
patch built with one version of kpatch-build to replace the same fix
bult with the other version of kpatch-build, we hit errors like:
[ 14.218706] sysfs: cannot create duplicate filename 'xxx/somefunc,1'
...
[ 14.219466] Call Trace:
[ 14.219468] <TASK>
[ 14.219469] dump_stack_lvl+0x47/0x60
[ 14.219474] sysfs_warn_dup.cold+0x17/0x27
[ 14.219476] sysfs_create_dir_ns+0x95/0xb0
[ 14.219479] kobject_add_internal+0x9e/0x260
[ 14.219483] kobject_add+0x68/0x80
[ 14.219485] ? kstrdup+0x3c/0xa0
[ 14.219486] klp_enable_patch+0x320/0x830
[ 14.219488] patch_init+0x443/0x1000 [ccc_0_6]
[ 14.219491] ? 0xffffffffa05eb000
[ 14.219492] do_one_initcall+0x2e/0x190
[ 14.219494] do_init_module+0x67/0x270
[ 14.219496] init_module_from_file+0x75/0xa0
[ 14.219499] idempotent_init_module+0x15a/0x240
[ 14.219501] __x64_sys_finit_module+0x61/0xc0
[ 14.219503] do_syscall_64+0x5b/0x160
[ 14.219505] entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 14.219507] RIP: 0033:0x7f545a4bd96d
...
[ 14.219516] kobject: kobject_add_internal failed for somefunc,1 with
-EEXIST, don't try to register things with the same name ...
This happens because klp_find_func() thinks somefunc with old_sympos==0
is not the same as somefunc with old_sympos==1, and klp_add_object_nops
adds another xxx/func,1 to the list of functions to patch.
Yes, this is a really rare case, and the toolchain (kpatch-build) should
be consistent with old_sympos. But I think we may want to fix the
behavior in kernel just in case.
---
kernel/livepatch/core.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 0e73fac55f8e..53c3b9b40c8b 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -88,8 +88,14 @@ static struct klp_func *klp_find_func(struct klp_object *obj,
struct klp_func *func;
klp_for_each_func(obj, func) {
+ /*
+ * Besides identical old_sympos, also condiser old_sympos
+ * of 0 and 1 are identical.
+ */
if ((strcmp(old_func->old_name, func->old_name) == 0) &&
- (old_func->old_sympos == func->old_sympos)) {
+ ((old_func->old_sympos == func->old_sympos) ||
+ (old_func->old_sympos == 0 && func->old_sympos == 1) ||
+ (old_func->old_sympos == 1 && func->old_sympos == 0))) {
return func;
}
}
--
2.47.3
^ permalink raw reply related
* [PATCH] selftests: livepatch: use canonical ftrace path
From: Fushuai Wang @ 2025-10-10 12:07 UTC (permalink / raw)
To: jpoimboe, jikos, mbenes, pmladek, joe.lawrence, shuah
Cc: live-patching, linux-kselftest, linux-kernel, Fushuai Wang
Since v4.1 kernel, a new interface for ftrace called "tracefs" was
introduced, which is usually mounted in /sys/kernel/tracing. Therefore,
tracing files can now be accessed via either the legacy path
/sys/kernel/debug/tracing or the newer path /sys/kernel/tracing.
Signed-off-by: Fushuai Wang <wangfushuai@baidu.com>
---
tools/testing/selftests/livepatch/functions.sh | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/livepatch/functions.sh b/tools/testing/selftests/livepatch/functions.sh
index 46991a029f7c..8ec0cb64ad94 100644
--- a/tools/testing/selftests/livepatch/functions.sh
+++ b/tools/testing/selftests/livepatch/functions.sh
@@ -10,7 +10,11 @@ SYSFS_KERNEL_DIR="/sys/kernel"
SYSFS_KLP_DIR="$SYSFS_KERNEL_DIR/livepatch"
SYSFS_DEBUG_DIR="$SYSFS_KERNEL_DIR/debug"
SYSFS_KPROBES_DIR="$SYSFS_DEBUG_DIR/kprobes"
-SYSFS_TRACING_DIR="$SYSFS_DEBUG_DIR/tracing"
+if [[ -e /sys/kernel/tracing/trace ]]; then
+ SYSFS_TRACING_DIR="$SYSFS_KERNEL_DIR/tracing"
+else
+ SYSFS_TRACING_DIR="$SYSFS_DEBUG_DIR/tracing"
+fi
# Kselftest framework requirement - SKIP code is 4
ksft_skip=4
--
2.36.1
^ permalink raw reply related
* Re: [PATCH v4 00/63] objtool,livepatch: klp-build livepatch module generation
From: Petr Mladek @ 2025-10-10 7:30 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: x86, linux-kernel, Miroslav Benes, Joe Lawrence, live-patching,
Song Liu, laokz, Jiri Kosina, Marcos Paulo de Souza, Weinan Liu,
Fazla Mehrab, Chen Zhongjin, Puranjay Mohan, Dylan Hatch,
Peter Zijlstra
In-Reply-To: <cover.1758067942.git.jpoimboe@kernel.org>
On Wed 2025-09-17 09:03:08, Josh Poimboeuf wrote:
> This series introduces new objtool features and a klp-build script to
> generate livepatch modules using a source .patch as input.
>
> This builds on concepts from the longstanding out-of-tree kpatch [1]
> project which began in 2012 and has been used for many years to generate
> livepatch modules for production kernels. However, this is a complete
> rewrite which incorporates hard-earned lessons from 12+ years of
> maintaining kpatch.
The series seems to be in a pretty good state, ready for linux-next, ...
Acked-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH] powerpc64/bpf: support direct_call on livepatch function
From: Hari Bathini @ 2025-10-10 7:17 UTC (permalink / raw)
To: Naveen N Rao
Cc: Madhavan Srinivasan, linuxppc-dev, Christophe Leroy,
Michael Ellerman, Nicholas Piggin, bpf, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Song Liu, Jiri Olsa,
Viktor Malik, live-patching, Josh Poimboeuf, Joe Lawrence,
Jiri Kosina, linux-trace-kernel, Steven Rostedt, Masami Hiramatsu,
Mark Rutland, Shung-Hsi Yu
In-Reply-To: <dvvv5cytyak2iquer7d6g57ttum3qcckupyahsqsmvpzfjbyni@wbsr77swnrcl>
On 09/10/25 4:57 pm, Naveen N Rao wrote:
> On Thu, Oct 09, 2025 at 11:19:45AM +0530, Hari Bathini wrote:
>>
>>
>> On 08/10/25 1:43 pm, Naveen N Rao wrote:
>>> On Mon, Oct 06, 2025 at 06:50:20PM +0530, Hari Bathini wrote:
>>>>
>>>>
>>>> On 06/10/25 1:22 pm, Naveen N Rao wrote:
>>>>> On Fri, Oct 03, 2025 at 12:57:54AM +0530, Hari Bathini wrote:
>>>>>> Today, livepatch takes precedence over direct_call. Instead, save the
>>>>>> state and make direct_call before handling livepatch.
>>>>>
>>>>> If we call into the BPF trampoline first and if we have
>>>>> BPF_TRAMP_F_CALL_ORIG set, does this result in the BPF trampoline
>>>>> calling the new copy of the live-patched function or the old one?
>>>>
>>>> Naveen, calls the new copy of the live-patched function..
>>>
>>> Hmm... I'm probably missing something.
>>>
>>> With ftrace OOL stubs, what I recall is that BPF trampoline derives the
>>> original function address from the OOL stub (which would be associated
>>> with the original function, not the livepatch one).
>>
>> Trampoline derives the address from LR.
>
> Does it? I'm referring to BPF_TRAMP_F_CALL_ORIG handling in
> __arch_prepare_bpf_trampoline().
> LR at BPF trampoline entry points at
> the ftrace OOL stub. We recover the "real LR" pointing to the function
> being traced from there so that we can call into it from within the BPF
> trampoline.
Naveen, from the snippet in livepatch_handler code shared below,
the LR at BPF trmapoline entry points at the 'nop' after the call
to trampoline with 'bnectrl cr1' in the updated livepatch_handler.
Mimic'ing ftrace OOL branch instruction in livepatch_handler
with 'b 1f' (the instruction after nop) to ensure the trmapoline
derives the real LR to '1f' and jumps back into the livepatch_handler..
+ /* Jump to the direct_call */
+ bnectrl cr1
+
+ /*
+ * The address to jump after direct call is deduced based on
ftrace OOL stub sequence.
+ * The seemingly insignificant couple of instructions below is
to mimic that here to
+ * jump back to the livepatch handler code below.
+ */
+ nop
+ b 1f
+
+ /*
+ * Restore the state for livepatching from the livepatch stack.
+ * Before that, check if livepatch stack is intact. Use r0 for it.
+ */
+1: mtctr r0
I should probably improve my comments for better readability..
- Hari
^ permalink raw reply
* Re: [PATCH v4 51/63] objtool/klp: Introduce klp diff subcommand for diffing object files
From: Josh Poimboeuf @ 2025-10-09 23:19 UTC (permalink / raw)
To: Petr Mladek
Cc: x86, linux-kernel, Miroslav Benes, Joe Lawrence, live-patching,
Song Liu, laokz, Jiri Kosina, Marcos Paulo de Souza, Weinan Liu,
Fazla Mehrab, Chen Zhongjin, Puranjay Mohan, Dylan Hatch,
Peter Zijlstra
In-Reply-To: <aOeqt32wQhB5jAD-@pathway.suse.cz>
On Thu, Oct 09, 2025 at 02:29:43PM +0200, Petr Mladek wrote:
> Sounds reasonable and I am fine with it. I have one more question
> before I give my ack ;-)
>
> I wonder about the patchset which better integrate callbacks with shadow
> variables and state API, see
> https://lore.kernel.org/r/20250115082431.5550-1-pmladek@suse.com
>
> I think that it should not be that big problem to update it on top
> of this patchset. It would require:
>
> + moving declarations from livepatch.h to livepatch_external.h
> + updating the macros in livepatch_helpers.h
> + update callback-related code in create_klp_sections()
>
> Or do you expect bigger problems, please?
Yeah, that should be pretty straightforward. I can help with that.
Right now there's not even a way to create a klp_state. (not sure if
anybody's actually using that feature today?)
For your patch set we can add a macro to livepatch_helpers.h for adding
a state (and its callbacks). And then corresponding code in
create_klp_sections() as you mentioned, and a small change to
scripts/livepatch/init.c to set the klp_patch.states pointer.
--
Josh
^ permalink raw reply
* Re: [PATCH v4 51/63] objtool/klp: Introduce klp diff subcommand for diffing object files
From: Petr Mladek @ 2025-10-09 12:29 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: x86, linux-kernel, Miroslav Benes, Joe Lawrence, live-patching,
Song Liu, laokz, Jiri Kosina, Marcos Paulo de Souza, Weinan Liu,
Fazla Mehrab, Chen Zhongjin, Puranjay Mohan, Dylan Hatch,
Peter Zijlstra
In-Reply-To: <bnipx2pvsyxcd27uhxw5rr5yugm7iuint6rg3lzt3hdm7vkeue@g3wzb7kyr5da>
On Wed 2025-10-08 08:27:45, Josh Poimboeuf wrote:
> On Wed, Oct 08, 2025 at 04:01:50PM +0200, Petr Mladek wrote:
> > On Wed 2025-09-17 09:03:59, Josh Poimboeuf wrote:
> > > +static int read_exports(void)
> > > +{
> > > + const char *symvers = "Module.symvers";
> > > + char line[1024], *path = NULL;
> > > + unsigned int line_num = 1;
> > > + FILE *file;
> > > +
> > > + file = fopen(symvers, "r");
> > > + if (!file) {
> > > + path = top_level_dir(symvers);
> > > + if (!path) {
> > > + ERROR("can't open '%s', \"objtool diff\" should be run from the kernel tree", symvers);
> > > + return -1;
> > > + }
> > > +
> > > + file = fopen(path, "r");
> > > + if (!file) {
> > > + ERROR_GLIBC("fopen");
> > > + return -1;
> > > + }
> > > + }
> > > +
> > > + while (fgets(line, 1024, file)) {
> >
> > Nit: It might be more safe to replace 1024 with sizeof(line).
> > It might be fixed later in a separate patch.
>
> Indeed.
>
> > > +/*
> > > + * Klp relocations aren't allowed for __jump_table and .static_call_sites if
> > > + * the referenced symbol lives in a kernel module, because such klp relocs may
> > > + * be applied after static branch/call init, resulting in code corruption.
> > > + *
> > > + * Validate a special section entry to avoid that. Note that an inert
> > > + * tracepoint is harmless enough, in that case just skip the entry and print a
> > > + * warning. Otherwise, return an error.
> > > + *
> > > + * This is only a temporary limitation which will be fixed when livepatch adds
> > > + * support for submodules: fully self-contained modules which are embedded in
> > > + * the top-level livepatch module's data and which can be loaded on demand when
> > > + * their corresponding to-be-patched module gets loaded. Then klp relocs can
> > > + * be retired.
> >
> > I wonder how temporary this is ;-) The comment looks optimistic. I am
> > just curious. Do you have any plans to implement the support for
> > the submodules... ?
>
> I actually already have a working POC for that, but didn't want to make
> the patch set even longer ;-)
Sure.
> It was surprisingly easy and straightforward to implement.
I am curious ;-)
> > PS: To make some expectations. I am not doing a deep review.
> > I am just looking at the patchset to see how far and mature
> > it is. And I just comment what catches my eye.
> >
> > My first impression is that it is already in a pretty good state.
> > And I do not see any big problem there. Well, some documentation
> > would be fine ;-)
> >
> > What are your plans, please?
>
> >From my perspective, it's testing well and in a good enough state for
> merging soon (after the merge window?), if there aren't any objections
> to that.
>
> There will be more patches to come, like the submodules and other arch
> support. And of course there will be bugs discovered by broader
> testing. But I think this is a good foundation to begin with.
>
> And the sooner we can get people using this, the sooner we can start
> deprecating kpatch-build, which would be really nice.
Sounds reasonable and I am fine with it. I have one more question
before I give my ack ;-)
I wonder about the patchset which better integrate callbacks with shadow
variables and state API, see
https://lore.kernel.org/r/20250115082431.5550-1-pmladek@suse.com
I think that it should not be that big problem to update it on top
of this patchset. It would require:
+ moving declarations from livepatch.h to livepatch_external.h
+ updating the macros in livepatch_helpers.h
+ update callback-related code in create_klp_sections()
Or do you expect bigger problems, please?
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH] powerpc64/bpf: support direct_call on livepatch function
From: Naveen N Rao @ 2025-10-09 11:27 UTC (permalink / raw)
To: Hari Bathini
Cc: Madhavan Srinivasan, linuxppc-dev, Christophe Leroy,
Michael Ellerman, Nicholas Piggin, bpf, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Song Liu, Jiri Olsa,
Viktor Malik, live-patching, Josh Poimboeuf, Joe Lawrence,
Jiri Kosina, linux-trace-kernel, Steven Rostedt, Masami Hiramatsu,
Mark Rutland, Shung-Hsi Yu
In-Reply-To: <42d72061-3d23-43db-bb02-d5f75333c924@linux.ibm.com>
On Thu, Oct 09, 2025 at 11:19:45AM +0530, Hari Bathini wrote:
>
>
> On 08/10/25 1:43 pm, Naveen N Rao wrote:
> > On Mon, Oct 06, 2025 at 06:50:20PM +0530, Hari Bathini wrote:
> > >
> > >
> > > On 06/10/25 1:22 pm, Naveen N Rao wrote:
> > > > On Fri, Oct 03, 2025 at 12:57:54AM +0530, Hari Bathini wrote:
> > > > > Today, livepatch takes precedence over direct_call. Instead, save the
> > > > > state and make direct_call before handling livepatch.
> > > >
> > > > If we call into the BPF trampoline first and if we have
> > > > BPF_TRAMP_F_CALL_ORIG set, does this result in the BPF trampoline
> > > > calling the new copy of the live-patched function or the old one?
> > >
> > > Naveen, calls the new copy of the live-patched function..
> >
> > Hmm... I'm probably missing something.
> >
> > With ftrace OOL stubs, what I recall is that BPF trampoline derives the
> > original function address from the OOL stub (which would be associated
> > with the original function, not the livepatch one).
>
> Trampoline derives the address from LR.
Does it? I'm referring to BPF_TRAMP_F_CALL_ORIG handling in
__arch_prepare_bpf_trampoline(). LR at BPF trampoline entry points at
the ftrace OOL stub. We recover the "real LR" pointing to the function
being traced from there so that we can call into it from within the BPF
trampoline.
- Naveen
^ permalink raw reply
* Re: [PATCH] powerpc64/bpf: support direct_call on livepatch function
From: Hari Bathini @ 2025-10-09 5:49 UTC (permalink / raw)
To: Naveen N Rao
Cc: Madhavan Srinivasan, linuxppc-dev, Christophe Leroy,
Michael Ellerman, Nicholas Piggin, bpf, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Song Liu, Jiri Olsa,
Viktor Malik, live-patching, Josh Poimboeuf, Joe Lawrence,
Jiri Kosina, linux-trace-kernel, Steven Rostedt, Masami Hiramatsu,
Mark Rutland, Shung-Hsi Yu
In-Reply-To: <unegysw3bihg32od7aham3npsdpm5govboo3uglorwsrjqfqfk@pbyzwwztmqtc>
On 08/10/25 1:43 pm, Naveen N Rao wrote:
> On Mon, Oct 06, 2025 at 06:50:20PM +0530, Hari Bathini wrote:
>>
>>
>> On 06/10/25 1:22 pm, Naveen N Rao wrote:
>>> On Fri, Oct 03, 2025 at 12:57:54AM +0530, Hari Bathini wrote:
>>>> Today, livepatch takes precedence over direct_call. Instead, save the
>>>> state and make direct_call before handling livepatch.
>>>
>>> If we call into the BPF trampoline first and if we have
>>> BPF_TRAMP_F_CALL_ORIG set, does this result in the BPF trampoline
>>> calling the new copy of the live-patched function or the old one?
>>
>> Naveen, calls the new copy of the live-patched function..
>
> Hmm... I'm probably missing something.
>
> With ftrace OOL stubs, what I recall is that BPF trampoline derives the
> original function address from the OOL stub (which would be associated
> with the original function, not the livepatch one).
Trampoline derives the address from LR. The below snippet
in livepatch_handler ensures the trampoline jumps to '1f'
label instead of the original function with LR updated:
+ /* Jump to the direct_call */
+ bnectrl cr1
+
+ /*
+ * The address to jump after direct call is deduced based on ftrace
OOL stub sequence.
+ * The seemingly insignificant couple of instructions below is to
mimic that here to
+ * jump back to the livepatch handler code below.
+ */
+ nop
+ b 1f
+
+ /*
+ * Restore the state for livepatching from the livepatch stack.
+ * Before that, check if livepatch stack is intact. Use r0 for it.
+ */
+1: mtctr r0
- Hari
^ permalink raw reply
* Re: [PATCH v4 51/63] objtool/klp: Introduce klp diff subcommand for diffing object files
From: Josh Poimboeuf @ 2025-10-08 15:27 UTC (permalink / raw)
To: Petr Mladek
Cc: x86, linux-kernel, Miroslav Benes, Joe Lawrence, live-patching,
Song Liu, laokz, Jiri Kosina, Marcos Paulo de Souza, Weinan Liu,
Fazla Mehrab, Chen Zhongjin, Puranjay Mohan, Dylan Hatch,
Peter Zijlstra
In-Reply-To: <aOZuzj0vhKPF1bcW@pathway.suse.cz>
On Wed, Oct 08, 2025 at 04:01:50PM +0200, Petr Mladek wrote:
> On Wed 2025-09-17 09:03:59, Josh Poimboeuf wrote:
> > +static int read_exports(void)
> > +{
> > + const char *symvers = "Module.symvers";
> > + char line[1024], *path = NULL;
> > + unsigned int line_num = 1;
> > + FILE *file;
> > +
> > + file = fopen(symvers, "r");
> > + if (!file) {
> > + path = top_level_dir(symvers);
> > + if (!path) {
> > + ERROR("can't open '%s', \"objtool diff\" should be run from the kernel tree", symvers);
> > + return -1;
> > + }
> > +
> > + file = fopen(path, "r");
> > + if (!file) {
> > + ERROR_GLIBC("fopen");
> > + return -1;
> > + }
> > + }
> > +
> > + while (fgets(line, 1024, file)) {
>
> Nit: It might be more safe to replace 1024 with sizeof(line).
> It might be fixed later in a separate patch.
Indeed.
> > +/*
> > + * Klp relocations aren't allowed for __jump_table and .static_call_sites if
> > + * the referenced symbol lives in a kernel module, because such klp relocs may
> > + * be applied after static branch/call init, resulting in code corruption.
> > + *
> > + * Validate a special section entry to avoid that. Note that an inert
> > + * tracepoint is harmless enough, in that case just skip the entry and print a
> > + * warning. Otherwise, return an error.
> > + *
> > + * This is only a temporary limitation which will be fixed when livepatch adds
> > + * support for submodules: fully self-contained modules which are embedded in
> > + * the top-level livepatch module's data and which can be loaded on demand when
> > + * their corresponding to-be-patched module gets loaded. Then klp relocs can
> > + * be retired.
>
> I wonder how temporary this is ;-) The comment looks optimistic. I am
> just curious. Do you have any plans to implement the support for
> the submodules... ?
I actually already have a working POC for that, but didn't want to make
the patch set even longer ;-)
It was surprisingly easy and straightforward to implement.
> PS: To make some expectations. I am not doing a deep review.
> I am just looking at the patchset to see how far and mature
> it is. And I just comment what catches my eye.
>
> My first impression is that it is already in a pretty good state.
> And I do not see any big problem there. Well, some documentation
> would be fine ;-)
>
> What are your plans, please?
From my perspective, it's testing well and in a good enough state for
merging soon (after the merge window?), if there aren't any objections
to that.
There will be more patches to come, like the submodules and other arch
support. And of course there will be bugs discovered by broader
testing. But I think this is a good foundation to begin with.
And the sooner we can get people using this, the sooner we can start
deprecating kpatch-build, which would be really nice.
--
Josh
^ permalink raw reply
* Re: [PATCH v4 51/63] objtool/klp: Introduce klp diff subcommand for diffing object files
From: Petr Mladek @ 2025-10-08 14:01 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: x86, linux-kernel, Miroslav Benes, Joe Lawrence, live-patching,
Song Liu, laokz, Jiri Kosina, Marcos Paulo de Souza, Weinan Liu,
Fazla Mehrab, Chen Zhongjin, Puranjay Mohan, Dylan Hatch,
Peter Zijlstra
In-Reply-To: <702078edac02ecf79f869575f06c5b2dba8cd768.1758067943.git.jpoimboe@kernel.org>
On Wed 2025-09-17 09:03:59, Josh Poimboeuf wrote:
> Add a new klp diff subcommand which performs a binary diff between two
> object files and extracts changed functions into a new object which can
> then be linked into a livepatch module.
>
> This builds on concepts from the longstanding out-of-tree kpatch [1]
> project which began in 2012 and has been used for many years to generate
> livepatch modules for production kernels. However, this is a complete
> rewrite which incorporates hard-earned lessons from 12+ years of
> maintaining kpatch.
>
> --- /dev/null
> +++ b/tools/objtool/klp-diff.c
> +static int read_exports(void)
> +{
> + const char *symvers = "Module.symvers";
> + char line[1024], *path = NULL;
> + unsigned int line_num = 1;
> + FILE *file;
> +
> + file = fopen(symvers, "r");
> + if (!file) {
> + path = top_level_dir(symvers);
> + if (!path) {
> + ERROR("can't open '%s', \"objtool diff\" should be run from the kernel tree", symvers);
> + return -1;
> + }
> +
> + file = fopen(path, "r");
> + if (!file) {
> + ERROR_GLIBC("fopen");
> + return -1;
> + }
> + }
> +
> + while (fgets(line, 1024, file)) {
Nit: It might be more safe to replace 1024 with sizeof(line).
It might be fixed later in a separate patch.
> + char *sym, *mod, *type;
> + struct export *export;
> +
> + sym = strchr(line, '\t');
> + if (!sym) {
> + ERROR("malformed Module.symvers (sym) at line %d", line_num);
> + return -1;
> + }
> +
[...]
> +/*
> + * Klp relocations aren't allowed for __jump_table and .static_call_sites if
> + * the referenced symbol lives in a kernel module, because such klp relocs may
> + * be applied after static branch/call init, resulting in code corruption.
> + *
> + * Validate a special section entry to avoid that. Note that an inert
> + * tracepoint is harmless enough, in that case just skip the entry and print a
> + * warning. Otherwise, return an error.
> + *
> + * This is only a temporary limitation which will be fixed when livepatch adds
> + * support for submodules: fully self-contained modules which are embedded in
> + * the top-level livepatch module's data and which can be loaded on demand when
> + * their corresponding to-be-patched module gets loaded. Then klp relocs can
> + * be retired.
I wonder how temporary this is ;-) The comment looks optimistic. I am
just curious. Do you have any plans to implement the support for
the submodules... ?
> + * Return:
> + * -1: error: validation failed
> + * 1: warning: tracepoint skipped
> + * 0: success
> + */
> +static int validate_special_section_klp_reloc(struct elfs *e, struct symbol *sym)
> +{
> + bool static_branch = !strcmp(sym->sec->name, "__jump_table");
> + bool static_call = !strcmp(sym->sec->name, ".static_call_sites");
> + struct symbol *code_sym = NULL;
> + unsigned long code_offset = 0;
> + struct reloc *reloc;
> + int ret = 0;
> +
> + if (!static_branch && !static_call)
> + return 0;
> +
Best Regards,
Petr
PS: To make some expectations. I am not doing a deep review.
I am just looking at the patchset to see how far and mature
it is. And I just comment what catches my eye.
My first impression is that it is already in a pretty good state.
And I do not see any big problem there. Well, some documentation
would be fine ;-)
What are your plans, please?
^ permalink raw reply
* Re: [PATCH v3 3/6] kbuild/modpost: integrate klp-convert
From: Petr Mladek @ 2025-10-08 13:14 UTC (permalink / raw)
To: Lukas Hruska
Cc: mbenes, jpoimboe, joe.lawrence, live-patching, linux-kernel,
linux-kbuild, mpdesouza, Josh Poimboeuf
In-Reply-To: <20240827123052.9002-4-lhruska@suse.cz>
On Tue 2024-08-27 14:30:48, Lukas Hruska wrote:
> From: Josh Poimboeuf <jpoimboe@redhat.com>
>
> Call klp-convert for the livepatch modules after the final linking.
>
> Also update the modpost tool so that it does not warn about unresolved
> symbols matching the expected format which will be then resolved by
> klp-convert.
>
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -1676,10 +1680,18 @@ static void check_exports(struct module *mod)
> const char *basename;
> exp = find_symbol(s->name);
> if (!exp) {
> - if (!s->weak && nr_unresolved++ < MAX_UNRESOLVED_REPORTS)
> + if (!s->weak && nr_unresolved++ < MAX_UNRESOLVED_REPORTS) {
> + /*
> + * In case of livepatch module we allow
> + * unresolved symbol with a specific format
> + */
> + if (mod->is_livepatch &&
> + strncmp(s->name, KLP_SYM_RELA, strlen(KLP_SYM_RELA)) == 0)
> + break;
Just for record. There must be "continue" instead of "break".
Otherwise, the function does not check the remaining symbols.
It won't copy CRCs of exported symbols. Finally, depmod would
complain about incompatible versions of symbols.
> modpost_log(warn_unresolved ? LOG_WARN : LOG_ERROR,
> "\"%s\" [%s.ko] undefined!\n",
> s->name, mod->name);
> + }
> continue;
> }
> if (exp->module == mod) {
Best Regards,
Petr
PS: I am not sure if this patchset would ever reach upstream.
But we found this bug when using the tool...
^ permalink raw reply
* Re: [PATCH] powerpc64/bpf: support direct_call on livepatch function
From: Naveen N Rao @ 2025-10-08 8:13 UTC (permalink / raw)
To: Hari Bathini
Cc: Madhavan Srinivasan, linuxppc-dev, Christophe Leroy,
Michael Ellerman, Nicholas Piggin, bpf, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Song Liu, Jiri Olsa,
Viktor Malik, live-patching, Josh Poimboeuf, Joe Lawrence,
Jiri Kosina, linux-trace-kernel, Steven Rostedt, Masami Hiramatsu,
Mark Rutland, Shung-Hsi Yu
In-Reply-To: <17f49a63-eccb-4075-91dd-b1f37aa762c7@linux.ibm.com>
On Mon, Oct 06, 2025 at 06:50:20PM +0530, Hari Bathini wrote:
>
>
> On 06/10/25 1:22 pm, Naveen N Rao wrote:
> > On Fri, Oct 03, 2025 at 12:57:54AM +0530, Hari Bathini wrote:
> > > Today, livepatch takes precedence over direct_call. Instead, save the
> > > state and make direct_call before handling livepatch.
> >
> > If we call into the BPF trampoline first and if we have
> > BPF_TRAMP_F_CALL_ORIG set, does this result in the BPF trampoline
> > calling the new copy of the live-patched function or the old one?
>
> Naveen, calls the new copy of the live-patched function..
Hmm... I'm probably missing something.
With ftrace OOL stubs, what I recall is that BPF trampoline derives the
original function address from the OOL stub (which would be associated
with the original function, not the livepatch one). This should mean
that the trampoline continues to invoke the original function.
- Naveen
^ permalink raw reply
* [PATCH v2] powerpc64/bpf: support direct_call on livepatch function
From: Hari Bathini @ 2025-10-08 8:50 UTC (permalink / raw)
To: Madhavan Srinivasan
Cc: linuxppc-dev, Christophe Leroy, Naveen N. Rao, Michael Ellerman,
Nicholas Piggin, bpf, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Song Liu, Jiri Olsa, Viktor Malik, live-patching,
Josh Poimboeuf, Joe Lawrence, Jiri Kosina, linux-trace-kernel,
Steven Rostedt, Masami Hiramatsu, Mark Rutland, Shung-Hsi Yu
Today, livepatch takes precedence over direct_call. Instead, save the
state and make direct_call before handling livepatch. This change
inadvertly skips livepatch stack restore, when an attached fmod_ret
program fails. To handle this scenario, set cr0.eq bit to indicate
livepatch is active while making the direct_call, save the expected
livepatch stack state on the trampoline stack and restore it, if and
when required, during do_fexit in the trampoline code.
Reported-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
Closes: https://lore.kernel.org/all/rwmwrvvtg3pd7qrnt3of6dideioohwhsplancoc2gdrjran7bg@j5tqng6loymr/
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
---
Changes in v2:
* Fixed compile error reported by kernel test bot for !CONFIG_LIVEPATCH
arch/powerpc/include/asm/livepatch.h | 15 +++++
arch/powerpc/kernel/trace/ftrace_entry.S | 74 +++++++++++++++++++----
arch/powerpc/net/bpf_jit_comp.c | 75 ++++++++++++++++++++++++
3 files changed, 154 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/livepatch.h b/arch/powerpc/include/asm/livepatch.h
index d044a1fd4f44..356c1eb46f5d 100644
--- a/arch/powerpc/include/asm/livepatch.h
+++ b/arch/powerpc/include/asm/livepatch.h
@@ -7,6 +7,20 @@
#ifndef _ASM_POWERPC_LIVEPATCH_H
#define _ASM_POWERPC_LIVEPATCH_H
+#ifdef CONFIG_LIVEPATCH_64
+#define LIVEPATCH_STACK_MAGIC_OFFSET 8
+#define LIVEPATCH_STACK_LR_OFFSET 16
+#define LIVEPATCH_STACK_TOC_OFFSET 24
+
+#if defined(CONFIG_PPC_FTRACE_OUT_OF_LINE) && defined(CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS)
+#define LIVEPATCH_STACK_FRAME_SIZE 32 /* Allocate 4 x 8 bytes (to save new NIP as well) */
+#define LIVEPATCH_STACK_NIP_OFFSET 32
+#else
+#define LIVEPATCH_STACK_FRAME_SIZE 24 /* Allocate 3 x 8 bytes */
+#endif
+#endif
+
+#ifndef __ASSEMBLY__
#include <linux/sched.h>
#include <linux/sched/task_stack.h>
@@ -20,4 +34,5 @@ static inline void klp_init_thread_info(struct task_struct *p)
static inline void klp_init_thread_info(struct task_struct *p) { }
#endif
+#endif /* !__ASSEMBLY__ */
#endif /* _ASM_POWERPC_LIVEPATCH_H */
diff --git a/arch/powerpc/kernel/trace/ftrace_entry.S b/arch/powerpc/kernel/trace/ftrace_entry.S
index 6599fe3c6234..b98f12f378b1 100644
--- a/arch/powerpc/kernel/trace/ftrace_entry.S
+++ b/arch/powerpc/kernel/trace/ftrace_entry.S
@@ -8,6 +8,7 @@
#include <asm/ppc_asm.h>
#include <asm/asm-offsets.h>
#include <asm/ftrace.h>
+#include <asm/livepatch.h>
#include <asm/ppc-opcode.h>
#include <asm/thread_info.h>
#include <asm/bug.h>
@@ -244,6 +245,8 @@
/* jump after _mcount site */
#ifdef CONFIG_PPC_FTRACE_OUT_OF_LINE
#ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
+ /* For direct_call, set cr0.eq bit only if livepatch is active */
+ crclr 4*cr0+eq
bnectr cr1
#endif
/*
@@ -306,10 +309,14 @@ ftrace_no_trace:
mtctr r12
REST_GPRS(11, 12, r1)
addi r1, r1, SWITCH_FRAME_SIZE+STACK_FRAME_MIN_SIZE
+ /* For direct_call, set cr0.eq bit only if livepatch is active */
+ crclr 4*cr0+eq
bctr
.Lftrace_direct_call:
mtctr r12
addi r1, r1, SWITCH_FRAME_SIZE+STACK_FRAME_MIN_SIZE
+ /* For direct_call, set cr0.eq bit only if livepatch is active */
+ crclr 4*cr0+eq
bctr
SYM_FUNC_START(ftrace_stub_direct_tramp)
blr
@@ -340,25 +347,72 @@ SYM_FUNC_END(ftrace_stub_direct_tramp)
livepatch_handler:
ld r12, PACA_THREAD_INFO(r13)
- /* Allocate 3 x 8 bytes */
ld r11, TI_livepatch_sp(r12)
- addi r11, r11, 24
+ /* Allocate stack to save LR, TOC & optionally NIP (in case of direct_call) */
+ addi r11, r11, LIVEPATCH_STACK_FRAME_SIZE
std r11, TI_livepatch_sp(r12)
/* Store stack end marker */
lis r12, STACK_END_MAGIC@h
ori r12, r12, STACK_END_MAGIC@l
- std r12, -8(r11)
+ std r12, -LIVEPATCH_STACK_MAGIC_OFFSET(r11)
/* Save toc & real LR on livepatch stack */
- std r2, -24(r11)
+ std r2, -LIVEPATCH_STACK_TOC_OFFSET(r11)
#ifndef CONFIG_PPC_FTRACE_OUT_OF_LINE
mflr r12
- std r12, -16(r11)
+ std r12, -LIVEPATCH_STACK_LR_OFFSET(r11)
mfctr r12
#else
- std r0, -16(r11)
+ std r0, -LIVEPATCH_STACK_LR_OFFSET(r11)
mflr r12
+
+ /* Also, save new NIP on livepatch stack before the direct_call */
+#ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
+ std r12, -LIVEPATCH_STACK_NIP_OFFSET(r11)
+
+ /* For direct_call, set cr0.eq bit to indicate livepatch is active */
+ crset 4*cr0+eq
+ /* Jump to the direct_call */
+ bnectrl cr1
+
+ /*
+ * The address to jump after direct call is deduced based on ftrace OOL stub sequence.
+ * The seemingly insignificant couple of instructions below is to mimic that here to
+ * jump back to the livepatch handler code below.
+ */
+ nop
+ b 1f
+
+ /*
+ * Restore the state for livepatching from the livepatch stack.
+ * Before that, check if livepatch stack is intact. Use r0 for it.
+ */
+1: mtctr r0
+ ld r12, PACA_THREAD_INFO(r13)
+ ld r11, TI_livepatch_sp(r12)
+ lis r0, STACK_END_MAGIC@h
+ ori r0, r0, STACK_END_MAGIC@l
+ ld r12, -LIVEPATCH_STACK_MAGIC_OFFSET(r11)
+1: tdne r12, r0
+ EMIT_BUG_ENTRY 1b, __FILE__, __LINE__ - 1, 0
+ mfctr r0
+
+ /*
+ * A change in r0 implies the direct_call is not done yet. The direct_call
+ * will take care of calling the original LR. Update r0 in livepatch stack
+ * with the new LR in the direct_call.
+ */
+ ld r12, -LIVEPATCH_STACK_LR_OFFSET(r11)
+ cmpd r12, r0
+ beq 1f
+ mflr r0
+ std r0, -LIVEPATCH_STACK_LR_OFFSET(r11)
+
+ /* Put new NIP back in r12 to proceed with livepatch handling */
+1: ld r12, -LIVEPATCH_STACK_NIP_OFFSET(r11)
+#endif /* CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS */
+
/* Put ctr in r12 for global entry and branch there */
mtctr r12
#endif
@@ -377,18 +431,18 @@ livepatch_handler:
/* Check stack marker hasn't been trashed */
lis r2, STACK_END_MAGIC@h
ori r2, r2, STACK_END_MAGIC@l
- ld r12, -8(r11)
+ ld r12, -LIVEPATCH_STACK_MAGIC_OFFSET(r11)
1: tdne r12, r2
EMIT_BUG_ENTRY 1b, __FILE__, __LINE__ - 1, 0
/* Restore LR & toc from livepatch stack */
- ld r12, -16(r11)
+ ld r12, -LIVEPATCH_STACK_LR_OFFSET(r11)
mtlr r12
- ld r2, -24(r11)
+ ld r2, -LIVEPATCH_STACK_TOC_OFFSET(r11)
/* Pop livepatch stack frame */
ld r12, PACA_THREAD_INFO(r13)
- subi r11, r11, 24
+ subi r11, r11, LIVEPATCH_STACK_FRAME_SIZE
std r11, TI_livepatch_sp(r12)
/* Return to original caller of live patched function */
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 88ad5ba7b87f..9b90acb1ea5f 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -19,6 +19,7 @@
#include <asm/kprobes.h>
#include <asm/text-patching.h>
+#include <asm/livepatch.h>
#include "bpf_jit.h"
@@ -684,6 +685,8 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im
struct bpf_tramp_links *fentry = &tlinks[BPF_TRAMP_FENTRY];
struct bpf_tramp_links *fexit = &tlinks[BPF_TRAMP_FEXIT];
struct codegen_context codegen_ctx, *ctx;
+ int __maybe_unused livepatch_sp_off = 0;
+ bool __maybe_unused handle_lp = false;
u32 *image = (u32 *)rw_image;
ppc_inst_t branch_insn;
u32 *branches = NULL;
@@ -716,6 +719,8 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im
* dummy frame for unwind [ back chain 1 ] --
* [ padding ] align stack frame
* r4_off [ r4 (tailcallcnt) ] optional - 32-bit powerpc
+ * [ *current.TI.lp_sp ]
+ * livepatch_sp_off [ current.TI.lp_sp ] optional - livepatch stack info
* alt_lr_off [ real lr (ool stub)] optional - actual lr
* [ r26 ]
* nvr_off [ r25 ] nvr save area
@@ -780,11 +785,23 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im
nvr_off = bpf_frame_size;
bpf_frame_size += 2 * SZL;
+
/* Optional save area for actual LR in case of ool ftrace */
if (IS_ENABLED(CONFIG_PPC_FTRACE_OUT_OF_LINE)) {
alt_lr_off = bpf_frame_size;
bpf_frame_size += SZL;
+ if (IS_ENABLED(CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS)) {
+ handle_lp = (func_ptr_is_kernel_text(func_addr) && fmod_ret->nr_links &&
+ (flags & BPF_TRAMP_F_CALL_ORIG));
+ }
+ }
+
+#ifdef CONFIG_LIVEPATCH_64
+ if (handle_lp) {
+ livepatch_sp_off = bpf_frame_size;
+ bpf_frame_size += 2 * SZL;
}
+#endif
if (IS_ENABLED(CONFIG_PPC32)) {
if (nr_regs < 2) {
@@ -822,6 +839,32 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im
if (IS_ENABLED(CONFIG_PPC32) && nr_regs < 2)
EMIT(PPC_RAW_STL(_R4, _R1, r4_off));
+#ifdef CONFIG_LIVEPATCH_64
+ /* Save expected livepatch stack state on the trampoline stack */
+ if (handle_lp) {
+ /*
+ * The caller is expected to set cr0.eq bit, if livepatch was active on it.
+ *
+ * If livepatch is active, save address & the expected value of
+ * livepatch stack pointer on the trampoline stack.
+ * Else, set both of them to 0.
+ */
+ PPC_BCC_SHORT(COND_EQ, (ctx->idx + 5) * 4);
+ EMIT(PPC_RAW_LI(_R12, 0));
+ EMIT(PPC_RAW_STL(_R12, _R1, livepatch_sp_off));
+ EMIT(PPC_RAW_STL(_R12, _R1, livepatch_sp_off + SZL));
+ PPC_JMP((ctx->idx + 7) * 4);
+
+ EMIT(PPC_RAW_LL(_R12, _R13, offsetof(struct paca_struct, __current) +
+ offsetof(struct task_struct, thread_info)));
+ EMIT(PPC_RAW_ADDI(_R12, _R12, offsetof(struct thread_info, livepatch_sp)));
+ EMIT(PPC_RAW_STL(_R12, _R1, livepatch_sp_off));
+ EMIT(PPC_RAW_LL(_R12, _R12, 0));
+ EMIT(PPC_RAW_ADDI(_R12, _R12, -LIVEPATCH_STACK_FRAME_SIZE));
+ EMIT(PPC_RAW_STL(_R12, _R1, livepatch_sp_off + SZL));
+ }
+#endif
+
bpf_trampoline_save_args(image, ctx, func_frame_offset, nr_regs, regs_off);
/* Save our return address */
@@ -932,6 +975,38 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im, void *rw_im
image[branches[i]] = ppc_inst_val(branch_insn);
}
+#ifdef CONFIG_LIVEPATCH_64
+ /*
+ * Restore livepatch stack state if livepatch was active & an attached
+ * fmod_ret program failed.
+ */
+ if (handle_lp) {
+ EMIT(PPC_RAW_LL(_R12, _R1, livepatch_sp_off + SZL));
+ EMIT(PPC_RAW_CMPLI(_R12, 0));
+
+ /*
+ * If expected value (_R12) of livepatch stack pointer saved on the
+ * trampoline stack is 0, livepatch was not active. Skip the rest.
+ */
+ PPC_BCC_SHORT(COND_EQ, (ctx->idx + 7) * 4);
+
+ EMIT(PPC_RAW_LL(_R25, _R1, livepatch_sp_off));
+ EMIT(PPC_RAW_LL(_R25, _R25, 0));
+
+ /*
+ * If the expected value (_R12) of livepatch stack pointer saved on the
+ * trampoline stack is not the same as actual value (_R25), it implies
+ * fmod_ret program failed and skipped calling the traced/livepatch'ed
+ * function. The livepatch'ed function did not get a chance to tear down
+ * the livepatch stack it setup. Take care of that here in do_fexit.
+ */
+ EMIT(PPC_RAW_CMPD(_R12, _R25));
+ PPC_BCC_SHORT(COND_EQ, (ctx->idx + 3) * 4);
+ EMIT(PPC_RAW_LL(_R25, _R1, livepatch_sp_off));
+ EMIT(PPC_RAW_STL(_R12, _R25, 0));
+ }
+#endif
+
for (i = 0; i < fexit->nr_links; i++)
if (invoke_bpf_prog(image, ro_image, ctx, fexit->links[i], regs_off, retval_off,
run_ctx_off, false)) {
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v4 00/63] objtool,livepatch: klp-build livepatch module generation
From: Joe Lawrence @ 2025-10-07 17:38 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: x86, linux-kernel, Petr Mladek, Miroslav Benes, live-patching,
Song Liu, laokz, Jiri Kosina, Marcos Paulo de Souza, Weinan Liu,
Fazla Mehrab, Chen Zhongjin, Puranjay Mohan, Dylan Hatch,
Peter Zijlstra
In-Reply-To: <cover.1758067942.git.jpoimboe@kernel.org>
On Wed, Sep 17, 2025 at 09:03:08AM -0700, Josh Poimboeuf wrote:
> Changes since v3 (https://lore.kernel.org/cover.1750980516.git.jpoimboe@kernel.org):
>
> - Get rid of the SHF_MERGE+SHF_WRITE toolchain shenanigans in favor of
> simple .discard.annotate_data annotations
> - Fix potential double free in elf_create_reloc()
> - Sync interval_tree_generic.h (Peter)
> - Refactor prefix symbol creation error handling
> - Rebase on tip/master and fix new issue (--checksum getting added with --noabs)
>
> (v3..v4 diff below)
>
> ----
>
> This series introduces new objtool features and a klp-build script to
> generate livepatch modules using a source .patch as input.
>
> This builds on concepts from the longstanding out-of-tree kpatch [1]
> project which began in 2012 and has been used for many years to generate
> livepatch modules for production kernels. However, this is a complete
> rewrite which incorporates hard-earned lessons from 12+ years of
> maintaining kpatch.
>
> Key improvements compared to kpatch-build:
>
> - Integrated with objtool: Leverages objtool's existing control-flow
> graph analysis to help detect changed functions.
>
> - Works on vmlinux.o: Supports late-linked objects, making it
> compatible with LTO, IBT, and similar.
>
> - Simplified code base: ~3k fewer lines of code.
>
> - Upstream: No more out-of-tree #ifdef hacks, far less cruft.
>
> - Cleaner internals: Vastly simplified logic for symbol/section/reloc
> inclusion and special section extraction.
>
> - Robust __LINE__ macro handling: Avoids false positive binary diffs
> caused by the __LINE__ macro by introducing a fix-patch-lines script
> which injects #line directives into the source .patch to preserve
> the original line numbers at compile time.
>
> The primary user interface is the klp-build script which does the
> following:
>
> - Builds an original kernel with -function-sections and
> -fdata-sections, plus objtool function checksumming.
>
> - Applies the .patch file and rebuilds the kernel using the same
> options.
>
> - Runs 'objtool klp diff' to detect changed functions and generate
> intermediate binary diff objects.
>
> - Builds a kernel module which links the diff objects with some
> livepatch module init code (scripts/livepatch/init.c).
>
> - Finalizes the livepatch module (aka work around linker wreckage)
> using 'objtool klp post-link'.
>
> I've tested with a variety of patches on defconfig and Fedora-config
> kernels with both GCC and Clang.
>
> These patches can also be found at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git klp-build-v3
>
> Please test!
>
For v4.1, with several dozen small, CVE input patches and gcc 14 +
CentOS-Steam-10 config:
Tested-off-by: Joe Lawrence <joe.lawrence@redhat.com>
--
Joe
^ permalink raw reply
* Re: [PATCH] powerpc64/bpf: support direct_call on livepatch function
From: Hari Bathini @ 2025-10-06 13:20 UTC (permalink / raw)
To: Naveen N Rao
Cc: Madhavan Srinivasan, linuxppc-dev, Christophe Leroy,
Michael Ellerman, Nicholas Piggin, bpf, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Song Liu, Jiri Olsa,
Viktor Malik, live-patching, Josh Poimboeuf, Joe Lawrence,
Jiri Kosina, linux-trace-kernel, Steven Rostedt, Masami Hiramatsu,
Mark Rutland, Shung-Hsi Yu
In-Reply-To: <amwerofvasp7ssmq3zlrjakqj5aygyrgplcqzweno4ef42tiav@uex2ildqjvx2>
On 06/10/25 1:22 pm, Naveen N Rao wrote:
> On Fri, Oct 03, 2025 at 12:57:54AM +0530, Hari Bathini wrote:
>> Today, livepatch takes precedence over direct_call. Instead, save the
>> state and make direct_call before handling livepatch.
>
> If we call into the BPF trampoline first and if we have
> BPF_TRAMP_F_CALL_ORIG set, does this result in the BPF trampoline
> calling the new copy of the live-patched function or the old one?
Naveen, calls the new copy of the live-patched function..
- Hari
^ permalink raw reply
* Re: [PATCH] powerpc64/bpf: support direct_call on livepatch function
From: Naveen N Rao @ 2025-10-06 7:52 UTC (permalink / raw)
To: Hari Bathini
Cc: Madhavan Srinivasan, linuxppc-dev, Christophe Leroy,
Michael Ellerman, Nicholas Piggin, bpf, Alexei Starovoitov,
Daniel Borkmann, Andrii Nakryiko, Song Liu, Jiri Olsa,
Viktor Malik, live-patching, Josh Poimboeuf, Joe Lawrence,
Jiri Kosina, linux-trace-kernel, Steven Rostedt, Masami Hiramatsu,
Mark Rutland, Shung-Hsi Yu
In-Reply-To: <20251002192755.86441-1-hbathini@linux.ibm.com>
On Fri, Oct 03, 2025 at 12:57:54AM +0530, Hari Bathini wrote:
> Today, livepatch takes precedence over direct_call. Instead, save the
> state and make direct_call before handling livepatch.
If we call into the BPF trampoline first and if we have
BPF_TRAMP_F_CALL_ORIG set, does this result in the BPF trampoline
calling the new copy of the live-patched function or the old one?
- Naveen
^ 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