* BPF fentry/fexit trampolines stall livepatch stalls transition due to missing ORC unwind metadata
From: Andrey Grodzovsky @ 2025-11-19 15:41 UTC (permalink / raw)
To: bpf, live-patching
Cc: DL Linux Open Source Team, Petr Mladek, Song Liu, andrii,
Raja Khan
Hello BPF and livepatch teams,
This is somewhat a followup on
https://lists.ubuntu.com/archives/kernel-team/2025-October/163881.html
as we continue encounter issues and conflicts between BPF and livepatch.
We've encountered an issue between BPF fentry/fexit trampolines and
kernel livepatching (kpatch/livepatch) on x86_64 systems with ORC
unwinder enabled. I'm reaching out to understand if this is a known
limitation and to explore potential solutions. I assume it's known as I
see information along this lines in
https://www.kernel.org/doc/Documentation/livepatch/reliable-stacktrace.rst
Problem Summary
When BPF programs attach to kernel functions using fentry/fexit hooks,
the resulting JIT-compiled trampolines lack ORC unwind metadata. This
causes livepatch transition stall when threads are blocked in hooked
functions, as the stack becomes unreliable for unwinding purposes.
In our case the environment is
- RHEL 9.6 (kernel 5.14.0-570.17.1.el9_6.x86_64)
- CONFIG_UNWINDER_ORC=y
- CONFIG_BPF_JIT_ALWAYS_ON=y
- BPF fentry/fexit hooks on inet_recvmsg()
Scenario:
1. BPF program attached to inet_recvmsg via fentry/fexit (creates BPF
trampoline)
2. CIFS filesystem mounted (creates cifsd kernel thread)
3. cifsd thread blocks in inet_recvmsg → BPF trampoline is on the stack
4. Attempt to load kpatch module
5. Livepatch transition stalls indefinitely
Error Message (repeated every ~1 second):
livepatch: klp_try_switch_task: cifsd:2886 has an unreliable stack
Stack trace showing BPF trampoline:
cifsd D 0 2886
Call Trace:
wait_woken+0x50/0x60
sk_wait_data+0x176/0x190
tcp_recvmsg_locked+0x234/0x920
tcp_recvmsg+0x78/0x210
inet_recvmsg+0x5c/0x140
bpf_trampoline_6442469985+0x89/0x130 ← NO ORC metadata
sock_recvmsg+0x95/0xa0
cifs_readv_from_socket+0x1ca/0x2d0 [cifs]
...
As far as I understand and please correct me if it's wrong -
The failure occurs in arch/x86/kernel/unwind_orc.c
orc = orc_find(state->signal ? state->ip : state->ip - 1);
if (!orc) {
/*
* As a fallback, try to assume this code uses a frame pointer.
* This is useful for generated code, like BPF, which ORC
* doesn't know about. This is just a guess, so the rest of
* the unwind is no longer considered reliable.
*/
orc = &orc_fp_entry;
state->error = true; // ← Marks stack as unreliable
}
When orc_find() returns NULL for the BPF trampoline address, the
unwinder falls back to frame pointers and marks the stack unreliable.
This causes arch_stack_walk_reliable() to fail, which in turn causes
livepatch's klp_check_stack() to return -EINVAL before even checking if
to-be-patched functions are on the stack.
Key observations:
1. The kernel comment explicitly mentions "generated code, like BPF"
2. Documentation/livepatch/reliable-stacktrace.rst lists "Dynamically
generated code (e.g. eBPF)" as causing unreliable stacks
3. Native kernel functions have ORC metadata from objtool during build
4. Ftrace trampolines have special ORC handling via orc_ftrace_find()
5. BPF JIT trampolines have no such handling - Is this correct ?
Impact
This affects production systems where:
- Security/observability tools use BPF fentry/fexit hooks
- Live kernel patching is required for security updates
- Kernel threads may be blocked in hooked network/storage functions
The livepatch transition can stall for 60+ seconds before failing,
blocking critical security patches.
Questions for the Community
1. Is this a known limitation (I assume yes) ?
2. Runtime ORC generation? Could the BPF JIT generate ORC unwind entries
for trampolines, similar to how ftrace trampolines are handled?
3. Trampoline registration? Could BPF trampolines register their address
ranges with the ORC unwinder to avoid the "unreliable" marking?
4. Alternative unwinding? Could livepatch use an alternative unwinding
method when BPF trampolines are detected (e.g., frame pointers with
validation)?
5. Workarounds? I mention one bellow and I would be happy to hear if
anyone has a better idea to propose ?
The only possible workaround I see is switching everything from
trampoline based hooks to kprobe since I assume kprobes won't have this
issue
BPF kprobes use the ftrace infrastructure with kprobe_ftrace_handler,
which has ORC metadata and special handling in the unwinder. The stack
remains reliable:
inet_recvmsg+0x50/0x140 ← Has ORC metadata
kprobe_ftrace_handler+... ← Has ORC metadata
Problem with kprobes is obviously their performance penalty.
Additional Context
From arch/x86/net/bpf_jit_comp.c:3559:
bool bpf_jit_supports_exceptions(void)
{
/* We unwind through both kernel frames (starting from within bpf_throw
* call) and BPF frames. Therefore we require ORC unwinder to be
enabled
* to walk kernel frames and reach BPF frames in the stack trace.
*/
return IS_ENABLED(CONFIG_UNWINDER_ORC);
}
This shows that BPF already has some integration with ORC for exception
handling. Could this be extended to trampolines?
References
- Kernel: 5.14.0-570.17.1.el9_6.x86_64
- Code: arch/x86/kernel/unwind_orc.c:510-519
- Docs: Documentation/livepatch/reliable-stacktrace.rst lines 84-85, 111-112
I appreciate any guidance on whether this is something that could be
addressed in the kernel, or if we should focus on user-space workarounds.
Thanks,
Andrey
^ permalink raw reply
* Re: [PATCH v2 1/6] unwind: build kernel with sframe info
From: Jens Remus @ 2025-11-19 14:59 UTC (permalink / raw)
To: Dylan Hatch, Josh Poimboeuf, Steven Rostedt, Indu Bhagat,
Peter Zijlstra, Will Deacon, Catalin Marinas, Jiri Kosina
Cc: Roman Gushchin, Weinan Liu, Mark Rutland, Ian Rogers,
linux-toolchains, linux-kernel, live-patching, joe.lawrence,
Puranjay Mohan, Song Liu, Prasanna Kumar T S M, Heiko Carstens,
Vasily Gorbik
In-Reply-To: <20250904223850.884188-2-dylanbhatch@google.com>
Hello Dylan!
On 9/5/2025 12:38 AM, Dylan Hatch wrote:
> Use the -Wa,--gsframe flags to build the code, so GAS will generate
> a new .sframe section for the stack trace information.
> Currently, the sframe format only supports arm64 and x86_64
> architectures. Add this configuration on arm64 to enable sframe
> unwinder in the future.
>
> Signed-off-by: Weinan Liu <wnliu@google.com>
> Signed-off-by: Dylan Hatch <dylanbhatch@google.com>
> Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com>
> diff --git a/arch/Kconfig b/arch/Kconfig
> @@ -1782,4 +1782,10 @@ config ARCH_WANTS_PRE_LINK_VMLINUX
> config ARCH_HAS_CPU_ATTACK_VECTORS
> bool
>
> +config AS_SFRAME
> + def_bool $(as-instr,.cfi_sections .sframe\n.cfi_startproc\n.cfi_endproc)
As you will soon be requiring SFrame V2 with the new PC-relative FDE
function start address encoding you may want to extend this check as
follows:
config AS_SFRAME
def_bool y
depends on $(as-instr,.cfi_sections .sframe\n.cfi_startproc\n.cfi_endproc)
depends on $(success,printf "%b\n" ".cfi_sections .sframe\n.cfi_startproc\n.cfi_endproc" | $(CC) $(CLANG_FLAGS) -Wa$(comma)--fatal-warnings -c -x assembler-with-cpp -o "$$TMP" - && $(OBJDUMP) --sframe "$$TMP" | grep -q "SFRAME_VERSION_2")
depends on $(success,printf "%b\n" ".cfi_sections .sframe\n.cfi_startproc\n.cfi_endproc" | $(CC) $(CLANG_FLAGS) -Wa$(comma)--fatal-warnings -c -x assembler-with-cpp -o "$$TMP" - && $(OBJDUMP) --sframe "$$TMP" | grep -q "SFRAME_F_FDE_FUNC_START_PCREL")
Or you could change it into multiple config options, which might be
overkill:
config AS_SFRAME
def_bool $(as-instr,.cfi_sections .sframe\n.cfi_startproc\n.cfi_endproc)
config AS_SFRAME_V2
def_bool y
depends on AS_SFRAME
depends on $(success,printf "%b\n" ".cfi_sections .sframe\n.cfi_startproc\n.cfi_endproc" | $(CC) $(CLANG_FLAGS) -Wa$(comma)--fatal-warnings -c -x assembler-with-cpp -o "$$TMP" - && $(OBJDUMP) --sframe "$$TMP" | grep -q "SFRAME_VERSION_2")
config AS_SFRAME_V2_PCREL_FDE
def_bool y
depends on AS_SFRAME_V2
depends on $(success,printf "%b\n" ".cfi_sections .sframe\n.cfi_startproc\n.cfi_endproc" | $(CC) $(CLANG_FLAGS) -Wa$(comma)--fatal-warnings -c -x assembler-with-cpp -o "$$TMP" - && $(OBJDUMP) --sframe "$$TMP" | grep -q "SFRAME_F_FDE_FUNC_START_PCREL")
> +
> +config SFRAME_UNWIND_TABLE
> + bool
> +
> endmenu
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
+49-7031-16-1128 Office
jremus@de.ibm.com
IBM
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
^ permalink raw reply
* Re: [PATCH v2 6/6] unwind: arm64: Add reliable stacktrace with sframe unwinder.
From: Indu Bhagat @ 2025-11-19 7:12 UTC (permalink / raw)
To: Dylan Hatch, Josh Poimboeuf
Cc: Steven Rostedt, Peter Zijlstra, Will Deacon, Catalin Marinas,
Jiri Kosina, Roman Gushchin, Weinan Liu, Mark Rutland, Ian Rogers,
linux-toolchains, linux-kernel, live-patching, joe.lawrence,
Puranjay Mohan, Song Liu, Prasanna Kumar T S M
In-Reply-To: <CADBMgpzmzyQgs4K3XoYf5h=C7vv-FDfNb5wharucyeoxUKo4bg@mail.gmail.com>
On 11/18/25 7:17 PM, Dylan Hatch wrote:
>> For sframe v3, I believe Indu is planning to add support for marking the
>> outermost frame. That would be one definitive way to know that the
>> stack trace made it to the end.
> How would this work? Is there a way of determining at compile time
> which functions would end up being the outermost frame?
No, the compiler does not emit such a marker.
SFrame information is generated by assembler using the .cfi_*
directives. For the outermost functions, they need to be marked with a:
.cfi_undefined RA
where RA is the default return address register for the ABI.
This mechanism is formalised in the DWARF standard:
"If a Return Address register is defined in the virtual unwind table,
and its rule is undefined (for example, by DW_CFA_undefined), then there
is no return address and no call address, and the virtual unwind of
stack activations is complete."
SFrame relies on this to emit a marker for identifying outermost frame.
^ permalink raw reply
* Re: [PATCH v2 6/6] unwind: arm64: Add reliable stacktrace with sframe unwinder.
From: Dylan Hatch @ 2025-11-19 3:17 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Steven Rostedt, Indu Bhagat, Peter Zijlstra, Will Deacon,
Catalin Marinas, Jiri Kosina, Roman Gushchin, Weinan Liu,
Mark Rutland, Ian Rogers, linux-toolchains, linux-kernel,
live-patching, joe.lawrence, Puranjay Mohan, Song Liu,
Prasanna Kumar T S M
In-Reply-To: <eo5fod6csuininieur2lm6bxunmpbk6n3wtxajamrwqqpae3ja@o3eqwfp3u6su>
On Mon, Nov 17, 2025 at 3:01 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Fri, Nov 14, 2025 at 10:44:20PM -0800, Dylan Hatch wrote:
> > Sorry for the slow reply on this, I'm going to try and get a v3 out
> > sometime after next week.
> >
> > On Wed, Sep 17, 2025 at 4:41 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > >
> > > As far I can tell, the *only* error condition being checked is if it
> > > (successfully) fell back to frame pointers.
> >
> > By checking/handling error conditions, do you mean just marking the
> > state as unreliable in any case where the unwind isn't successful with
> > SFrame?
>
> Right, any sframe error it encounters along the way (including missing
> sframe) would be a reason to mark it as unreliable.
>
> > I'm thinking if I can make the unwind_next_frame_sframe() code
> > path handle the end of the stack correctly on its own, I can more
> > strictly mark the trace as unreliable if it encounters any error.
> >
> > >
> > > What if there was some bad or missing sframe data? Or some unexpected
> > > condition on the stack?
> > >
> > > Also, does the exception handling code have correct cfi/sframe metadata?
> > >
> > > In order for it to be "reliable", we need to know the unwind reached the
> > > end of the stack (e.g., the task pt_regs frame, from entry-from-user).
> >
> > It looks like the frame-pointer based method of handling the end of
> > the stack involves calling kunwind_next_frame_record_meta() to extract
> > and check frame_record_meta::type for FRAME_META_TYPE_FINAL. I think
> > this currently assumes (based on the definition of 'struct
> > frame_record') that the next FP and PC are right next to each other,
> > alongside the meta type. But the sframe format stores separate entries
> > for the FP and RA offsets, which makes extracting the meta type from
> > this information a little bit murky to me.
> >
> > Would it make sense to fall back to the frame pointer method for the
> > final stack frame? Or I guess I could define a new sframe-friendly
> > meta frame record format?
>
> For sframe v3, I believe Indu is planning to add support for marking the
> outermost frame. That would be one definitive way to know that the
> stack trace made it to the end.
How would this work? Is there a way of determining at compile time
which functions would end up being the outermost frame?
>
> Or, if the entry-from-user pt_regs frame is always stored at a certain
> offset compared to the end of the task stack page, that might be another
> way.
It looks like kunwind_next_frame_record_meta() uses this strategy
already. It checks that 'fp == &task_pt_regs(tsk)->stackframe' to
validate that it has in fact reached the end of the stack. It seems
like we need alternate versions of kunwind_next_frame_record_meta()
and kunwind_next_regs_pc() that use the CFA calculated from the sframe
data (instead of the frame pointer). Does that sound right?
Thanks,
Dylan
On Mon, Nov 17, 2025 at 3:01 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Fri, Nov 14, 2025 at 10:44:20PM -0800, Dylan Hatch wrote:
> > Sorry for the slow reply on this, I'm going to try and get a v3 out
> > sometime after next week.
> >
> > On Wed, Sep 17, 2025 at 4:41 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > >
> > > As far I can tell, the *only* error condition being checked is if it
> > > (successfully) fell back to frame pointers.
> >
> > By checking/handling error conditions, do you mean just marking the
> > state as unreliable in any case where the unwind isn't successful with
> > SFrame?
>
> Right, any sframe error it encounters along the way (including missing
> sframe) would be a reason to mark it as unreliable.
>
> > I'm thinking if I can make the unwind_next_frame_sframe() code
> > path handle the end of the stack correctly on its own, I can more
> > strictly mark the trace as unreliable if it encounters any error.
> >
> > >
> > > What if there was some bad or missing sframe data? Or some unexpected
> > > condition on the stack?
> > >
> > > Also, does the exception handling code have correct cfi/sframe metadata?
> > >
> > > In order for it to be "reliable", we need to know the unwind reached the
> > > end of the stack (e.g., the task pt_regs frame, from entry-from-user).
> >
> > It looks like the frame-pointer based method of handling the end of
> > the stack involves calling kunwind_next_frame_record_meta() to extract
> > and check frame_record_meta::type for FRAME_META_TYPE_FINAL. I think
> > this currently assumes (based on the definition of 'struct
> > frame_record') that the next FP and PC are right next to each other,
> > alongside the meta type. But the sframe format stores separate entries
> > for the FP and RA offsets, which makes extracting the meta type from
> > this information a little bit murky to me.
> >
> > Would it make sense to fall back to the frame pointer method for the
> > final stack frame? Or I guess I could define a new sframe-friendly
> > meta frame record format?
>
> For sframe v3, I believe Indu is planning to add support for marking the
> outermost frame. That would be one definitive way to know that the
> stack trace made it to the end.
>
> Or, if the entry-from-user pt_regs frame is always stored at a certain
> offset compared to the end of the task stack page, that might be another
> way.
>
> --
> Josh
^ permalink raw reply
* Re: [PATCH v2 0/6] unwind, arm64: add sframe unwinder for kernel
From: Indu Bhagat @ 2025-11-18 18:29 UTC (permalink / raw)
To: Puranjay Mohan, Josh Poimboeuf
Cc: Steven Rostedt, Dylan Hatch, Song Liu, Peter Zijlstra,
Will Deacon, Catalin Marinas, Jiri Kosina, Roman Gushchin,
Weinan Liu, Mark Rutland, Ian Rogers, linux-toolchains,
linux-kernel, live-patching, joe.lawrence, Puranjay Mohan
In-Reply-To: <CANk7y0hKH6vvWf3Lyc678uvF9YWStMzO-Sj8yb3sbS4=4dxC6Q@mail.gmail.com>
On 11/17/25 4:49 PM, Puranjay Mohan wrote:
> On Tue, Nov 18, 2025 at 1:10 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>>
>> On Mon, Nov 17, 2025 at 06:42:23PM -0500, Steven Rostedt wrote:
>>> On Mon, 17 Nov 2025 15:06:32 -0800
>>> Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>>>
>>>> The ORC unwinder marks the unwind "unreliable" if it has to fall back to
>>>> frame pointers.
>>>>
>>>> But that's not a problem for livepatch because it only[*] unwinds
>>>> blocked/sleeping tasks, which shouldn't have BPF on their stack anyway.
>>>>
>>>> [*] with one exception: the task calling into livepatch
>>>
>>> It may be a problem with preempted tasks right? I believe with PREEMPT_LAZY
>>> (and definitely with PREEMPT_RT) BPF programs can be preempted.
>>
>> In that case, then yes, that stack would be marked unreliable and
>> livepatch would have to go try and patch the task later.
>>
>> If it were an isolated case, that would be fine, but if BPF were
>> consistently on the same task's stack, it could stall the completion of
>> the livepatch indefinitely.
>>
>> I haven't (yet?) heard of BPF-induced livepatch stalls happening in
>> reality, but maybe it's only a matter of time :-/
>>
>> To fix that, I suppose we would need some kind of dynamic ORC
>> registration interface. Similar to what has been discussed with
>> sframe+JIT.
>
> I work with the BPF JITs and would be interested in exploring this further,
> can you point me to this discussion if it happened on the list.
>
We discussed SFrame/JIT topic earlier this year in our monthly SFrame
meetings. I can point you to the meeting notes in a separate email. We
had some discussion around:
- SFrame specification: Allow efficient addition, removal and update
of data in SFrame sections. A part of the challenge is in representing
the variety of frames a JIT may use.
- SFrame APIs with JIT: Efficient SFrame stack trace data
manipulation by JIT.
- Interface with Linux kernel: Efficient SFrame stack trace data
registration and update stack trace data.
It will be great to have more collaboration and brainstorming, and to
include BPF/JIT in the discussions.
>>
>> If BPF were to always use frame pointers then there would be only a very
>> limited set of ORC entries (either "frame pointer" or "undefined") for a
>> given BPF function and it shouldn't be too complicated.
>>
>> --
>> Josh
^ permalink raw reply
* Re: [PATCH v2 0/6] unwind, arm64: add sframe unwinder for kernel
From: Steven Rostedt @ 2025-11-18 18:20 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Puranjay Mohan, Dylan Hatch, Song Liu, Indu Bhagat,
Peter Zijlstra, Will Deacon, Catalin Marinas, Jiri Kosina,
Roman Gushchin, Weinan Liu, Mark Rutland, Ian Rogers,
linux-toolchains, linux-kernel, live-patching, joe.lawrence,
Puranjay Mohan
In-Reply-To: <bcxe5hhenqdodutgp7vd7b7aqn7emrlsezlu7stjjmfxgwc3gw@q3ggnid7ooyd>
On Mon, 17 Nov 2025 21:18:41 -0800
Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > > To fix that, I suppose we would need some kind of dynamic ORC
> > > registration interface. Similar to what has been discussed with
> > > sframe+JIT.
> >
> > I work with the BPF JITs and would be interested in exploring this further,
> > can you point me to this discussion if it happened on the list.
>
> Sorry, nothing specific has been discussed that I'm aware of :-)
Right, the only discussions have been at the monthly Sframe meetings about
needing to be able to handle this. But the actual implementation details
have not been figured out yet.
-- Steve
^ permalink raw reply
* Re: [PATCH 2/4] media: atomisp: Fix startup() section placement with -ffunction-sections
From: Peter Zijlstra @ 2025-11-18 8:57 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: x86, linux-kernel, live-patching, Hans de Goede,
Mauro Carvalho Chehab, linux-toolchains
In-Reply-To: <2a3d4d7fco4szxyrw33lorkhckjq4styfsaljxxwd3v4o42i5z@qdavomj5i2mu>
On Fri, Nov 14, 2025 at 12:43:10PM -0800, Josh Poimboeuf wrote:
> On Fri, Nov 14, 2025 at 09:56:57AM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 12, 2025 at 03:47:49PM -0800, Josh Poimboeuf wrote:
> > > When compiling the kernel with -ffunction-sections (e.g., for LTO,
> > > livepatch, dead code elimination, AutoFDO, or Propeller), the startup()
> > > function gets compiled into the .text.startup section. In some cases it
> > > can even be cloned into .text.startup.constprop.0 or
> > > .text.startup.isra.0.
> > >
> > > However, the .text.startup and .text.startup.* section names are already
> > > reserved for use by the compiler for __attribute__((constructor)) code.
> > >
> >
> > Urgh, that's a 'fun' one. Is this not a -ffunction-sections bug? I mean,
> > the compiler should never put regular non-reserved user symbols in a
> > section it has reserved for itself, right?
>
> Right, so there's no ambiguity *IF* we know in advance whether it was
> compiled with -ffunction-sections. If so, constructor code goes in
> .text.startup.*, and startup() goes in .text.startup or
> .text.startup.constprop.0 or .text.startup.isra.0.
>
> So it's not really a compiler bug because it's possible to disambiguate
> those.
>
> Problem is, we can have some objects compiled with -ffunction-sections,
> and some compiled without, in the same kernel. So the disambiguation
> isn't possible at link time, since for example .text.startup could be
> startup() with -ffunction-sections, or it could be
> __attribute__((constructor)) without -ffunction-sections.
>
> I attempted to describe all that in patch 4.
Egads, what a mess :-(
^ permalink raw reply
* Re: [PATCH v2 0/6] unwind, arm64: add sframe unwinder for kernel
From: Josh Poimboeuf @ 2025-11-18 5:18 UTC (permalink / raw)
To: Puranjay Mohan
Cc: Steven Rostedt, Dylan Hatch, Song Liu, Indu Bhagat,
Peter Zijlstra, Will Deacon, Catalin Marinas, Jiri Kosina,
Roman Gushchin, Weinan Liu, Mark Rutland, Ian Rogers,
linux-toolchains, linux-kernel, live-patching, joe.lawrence,
Puranjay Mohan
In-Reply-To: <CANk7y0hKH6vvWf3Lyc678uvF9YWStMzO-Sj8yb3sbS4=4dxC6Q@mail.gmail.com>
On Tue, Nov 18, 2025 at 01:49:06AM +0100, Puranjay Mohan wrote:
> On Tue, Nov 18, 2025 at 1:10 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> >
> > On Mon, Nov 17, 2025 at 06:42:23PM -0500, Steven Rostedt wrote:
> > > On Mon, 17 Nov 2025 15:06:32 -0800
> > > Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> > >
> > > > The ORC unwinder marks the unwind "unreliable" if it has to fall back to
> > > > frame pointers.
> > > >
> > > > But that's not a problem for livepatch because it only[*] unwinds
> > > > blocked/sleeping tasks, which shouldn't have BPF on their stack anyway.
> > > >
> > > > [*] with one exception: the task calling into livepatch
> > >
> > > It may be a problem with preempted tasks right? I believe with PREEMPT_LAZY
> > > (and definitely with PREEMPT_RT) BPF programs can be preempted.
> >
> > In that case, then yes, that stack would be marked unreliable and
> > livepatch would have to go try and patch the task later.
> >
> > If it were an isolated case, that would be fine, but if BPF were
> > consistently on the same task's stack, it could stall the completion of
> > the livepatch indefinitely.
> >
> > I haven't (yet?) heard of BPF-induced livepatch stalls happening in
> > reality, but maybe it's only a matter of time :-/
> >
> > To fix that, I suppose we would need some kind of dynamic ORC
> > registration interface. Similar to what has been discussed with
> > sframe+JIT.
>
> I work with the BPF JITs and would be interested in exploring this further,
> can you point me to this discussion if it happened on the list.
Sorry, nothing specific has been discussed that I'm aware of :-)
--
Josh
^ permalink raw reply
* Re: [PATCH v2 0/6] unwind, arm64: add sframe unwinder for kernel
From: Puranjay Mohan @ 2025-11-18 0:49 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Steven Rostedt, Dylan Hatch, Song Liu, Indu Bhagat,
Peter Zijlstra, Will Deacon, Catalin Marinas, Jiri Kosina,
Roman Gushchin, Weinan Liu, Mark Rutland, Ian Rogers,
linux-toolchains, linux-kernel, live-patching, joe.lawrence,
Puranjay Mohan
In-Reply-To: <cxxj6lzs226ost6js5vslm52bxblknjwd6llmu24h3bk742zjh@7iwwi5bafysq>
On Tue, Nov 18, 2025 at 1:10 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Mon, Nov 17, 2025 at 06:42:23PM -0500, Steven Rostedt wrote:
> > On Mon, 17 Nov 2025 15:06:32 -0800
> > Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> >
> > > The ORC unwinder marks the unwind "unreliable" if it has to fall back to
> > > frame pointers.
> > >
> > > But that's not a problem for livepatch because it only[*] unwinds
> > > blocked/sleeping tasks, which shouldn't have BPF on their stack anyway.
> > >
> > > [*] with one exception: the task calling into livepatch
> >
> > It may be a problem with preempted tasks right? I believe with PREEMPT_LAZY
> > (and definitely with PREEMPT_RT) BPF programs can be preempted.
>
> In that case, then yes, that stack would be marked unreliable and
> livepatch would have to go try and patch the task later.
>
> If it were an isolated case, that would be fine, but if BPF were
> consistently on the same task's stack, it could stall the completion of
> the livepatch indefinitely.
>
> I haven't (yet?) heard of BPF-induced livepatch stalls happening in
> reality, but maybe it's only a matter of time :-/
>
> To fix that, I suppose we would need some kind of dynamic ORC
> registration interface. Similar to what has been discussed with
> sframe+JIT.
I work with the BPF JITs and would be interested in exploring this further,
can you point me to this discussion if it happened on the list.
>
> If BPF were to always use frame pointers then there would be only a very
> limited set of ORC entries (either "frame pointer" or "undefined") for a
> given BPF function and it shouldn't be too complicated.
>
> --
> Josh
^ permalink raw reply
* Re: [PATCH v2 0/6] unwind, arm64: add sframe unwinder for kernel
From: Josh Poimboeuf @ 2025-11-18 0:10 UTC (permalink / raw)
To: Steven Rostedt
Cc: Dylan Hatch, Puranjay Mohan, Song Liu, Indu Bhagat,
Peter Zijlstra, Will Deacon, Catalin Marinas, Jiri Kosina,
Roman Gushchin, Weinan Liu, Mark Rutland, Ian Rogers,
linux-toolchains, linux-kernel, live-patching, joe.lawrence,
Puranjay Mohan
In-Reply-To: <20251117184223.3c03fe92@gandalf.local.home>
On Mon, Nov 17, 2025 at 06:42:23PM -0500, Steven Rostedt wrote:
> On Mon, 17 Nov 2025 15:06:32 -0800
> Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> > The ORC unwinder marks the unwind "unreliable" if it has to fall back to
> > frame pointers.
> >
> > But that's not a problem for livepatch because it only[*] unwinds
> > blocked/sleeping tasks, which shouldn't have BPF on their stack anyway.
> >
> > [*] with one exception: the task calling into livepatch
>
> It may be a problem with preempted tasks right? I believe with PREEMPT_LAZY
> (and definitely with PREEMPT_RT) BPF programs can be preempted.
In that case, then yes, that stack would be marked unreliable and
livepatch would have to go try and patch the task later.
If it were an isolated case, that would be fine, but if BPF were
consistently on the same task's stack, it could stall the completion of
the livepatch indefinitely.
I haven't (yet?) heard of BPF-induced livepatch stalls happening in
reality, but maybe it's only a matter of time :-/
To fix that, I suppose we would need some kind of dynamic ORC
registration interface. Similar to what has been discussed with
sframe+JIT.
If BPF were to always use frame pointers then there would be only a very
limited set of ORC entries (either "frame pointer" or "undefined") for a
given BPF function and it shouldn't be too complicated.
--
Josh
^ permalink raw reply
* Re: [PATCH v2 0/6] unwind, arm64: add sframe unwinder for kernel
From: Puranjay Mohan @ 2025-11-17 23:50 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Dylan Hatch, Song Liu, Steven Rostedt, Indu Bhagat,
Peter Zijlstra, Will Deacon, Catalin Marinas, Jiri Kosina,
Roman Gushchin, Weinan Liu, Mark Rutland, Ian Rogers,
linux-toolchains, linux-kernel, live-patching, joe.lawrence,
Puranjay Mohan
In-Reply-To: <nzmtsafrx5vjitgfpducjaa7kq747a3sler2vvyvfbxecutn3v@7ffl2ycnaoo2>
On Tue, Nov 18, 2025 at 12:06 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Fri, Nov 14, 2025 at 10:50:16PM -0800, Dylan Hatch wrote:
> > On Mon, Sep 29, 2025 at 12:55 PM Puranjay Mohan <puranjay12@gmail.com> wrote:
> > >
> > > I will try to debug this more but am just curious about BPF's
> > > interactions with sframe.
> > > The sframe data for bpf programs doesn't exist, so we would need to
> > > add that support
> > > and that wouldn't be trivial, given the BPF programs are JITed.
> > >
> > > Thanks,
> > > Puranjay
> >
> > From what I can tell, the ORC unwinder in x86 falls back to using
> > frame pointers in cases of generated code, like BPF. Would matching
> > this behavior in the sframe unwinder be a reasonable approach, at
> > least for the purposes of enabling reliable unwind for livepatch?
>
> The ORC unwinder marks the unwind "unreliable" if it has to fall back to
> frame pointers.
>
> But that's not a problem for livepatch because it only[*] unwinds
> blocked/sleeping tasks, which shouldn't have BPF on their stack anyway.
>
BPF programs can sleep, so wouldn't they show up in the stack?
Like if I am tracing a syscall with a bpf program attached using
fentry and the BPF program calls a bpf_arena_alloc_pages(), which can
sleep.
^ permalink raw reply
* Re: [PATCH v2 0/6] unwind, arm64: add sframe unwinder for kernel
From: Steven Rostedt @ 2025-11-17 23:42 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Dylan Hatch, Puranjay Mohan, Song Liu, Indu Bhagat,
Peter Zijlstra, Will Deacon, Catalin Marinas, Jiri Kosina,
Roman Gushchin, Weinan Liu, Mark Rutland, Ian Rogers,
linux-toolchains, linux-kernel, live-patching, joe.lawrence,
Puranjay Mohan
In-Reply-To: <nzmtsafrx5vjitgfpducjaa7kq747a3sler2vvyvfbxecutn3v@7ffl2ycnaoo2>
On Mon, 17 Nov 2025 15:06:32 -0800
Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> The ORC unwinder marks the unwind "unreliable" if it has to fall back to
> frame pointers.
>
> But that's not a problem for livepatch because it only[*] unwinds
> blocked/sleeping tasks, which shouldn't have BPF on their stack anyway.
>
> [*] with one exception: the task calling into livepatch
It may be a problem with preempted tasks right? I believe with PREEMPT_LAZY
(and definitely with PREEMPT_RT) BPF programs can be preempted.
-- Steve
^ permalink raw reply
* Re: [PATCH v2 0/6] unwind, arm64: add sframe unwinder for kernel
From: Josh Poimboeuf @ 2025-11-17 23:06 UTC (permalink / raw)
To: Dylan Hatch
Cc: Puranjay Mohan, Song Liu, Steven Rostedt, Indu Bhagat,
Peter Zijlstra, Will Deacon, Catalin Marinas, Jiri Kosina,
Roman Gushchin, Weinan Liu, Mark Rutland, Ian Rogers,
linux-toolchains, linux-kernel, live-patching, joe.lawrence,
Puranjay Mohan
In-Reply-To: <CADBMgpwZ32+shSa0SwO8y4G-Zw14ae-FcoWreA_ptMf08Mu9dA@mail.gmail.com>
On Fri, Nov 14, 2025 at 10:50:16PM -0800, Dylan Hatch wrote:
> On Mon, Sep 29, 2025 at 12:55 PM Puranjay Mohan <puranjay12@gmail.com> wrote:
> >
> > I will try to debug this more but am just curious about BPF's
> > interactions with sframe.
> > The sframe data for bpf programs doesn't exist, so we would need to
> > add that support
> > and that wouldn't be trivial, given the BPF programs are JITed.
> >
> > Thanks,
> > Puranjay
>
> From what I can tell, the ORC unwinder in x86 falls back to using
> frame pointers in cases of generated code, like BPF. Would matching
> this behavior in the sframe unwinder be a reasonable approach, at
> least for the purposes of enabling reliable unwind for livepatch?
The ORC unwinder marks the unwind "unreliable" if it has to fall back to
frame pointers.
But that's not a problem for livepatch because it only[*] unwinds
blocked/sleeping tasks, which shouldn't have BPF on their stack anyway.
[*] with one exception: the task calling into livepatch
--
Josh
^ permalink raw reply
* Re: [PATCH v2 6/6] unwind: arm64: Add reliable stacktrace with sframe unwinder.
From: Josh Poimboeuf @ 2025-11-17 23:01 UTC (permalink / raw)
To: Dylan Hatch
Cc: Steven Rostedt, Indu Bhagat, Peter Zijlstra, Will Deacon,
Catalin Marinas, Jiri Kosina, Roman Gushchin, Weinan Liu,
Mark Rutland, Ian Rogers, linux-toolchains, linux-kernel,
live-patching, joe.lawrence, Puranjay Mohan, Song Liu,
Prasanna Kumar T S M
In-Reply-To: <CADBMgpyVis+fRHLOv6BRPrT+0r8846MOutkmOgMbqytLVXh9Ag@mail.gmail.com>
On Fri, Nov 14, 2025 at 10:44:20PM -0800, Dylan Hatch wrote:
> Sorry for the slow reply on this, I'm going to try and get a v3 out
> sometime after next week.
>
> On Wed, Sep 17, 2025 at 4:41 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> >
> > As far I can tell, the *only* error condition being checked is if it
> > (successfully) fell back to frame pointers.
>
> By checking/handling error conditions, do you mean just marking the
> state as unreliable in any case where the unwind isn't successful with
> SFrame?
Right, any sframe error it encounters along the way (including missing
sframe) would be a reason to mark it as unreliable.
> I'm thinking if I can make the unwind_next_frame_sframe() code
> path handle the end of the stack correctly on its own, I can more
> strictly mark the trace as unreliable if it encounters any error.
>
> >
> > What if there was some bad or missing sframe data? Or some unexpected
> > condition on the stack?
> >
> > Also, does the exception handling code have correct cfi/sframe metadata?
> >
> > In order for it to be "reliable", we need to know the unwind reached the
> > end of the stack (e.g., the task pt_regs frame, from entry-from-user).
>
> It looks like the frame-pointer based method of handling the end of
> the stack involves calling kunwind_next_frame_record_meta() to extract
> and check frame_record_meta::type for FRAME_META_TYPE_FINAL. I think
> this currently assumes (based on the definition of 'struct
> frame_record') that the next FP and PC are right next to each other,
> alongside the meta type. But the sframe format stores separate entries
> for the FP and RA offsets, which makes extracting the meta type from
> this information a little bit murky to me.
>
> Would it make sense to fall back to the frame pointer method for the
> final stack frame? Or I guess I could define a new sframe-friendly
> meta frame record format?
For sframe v3, I believe Indu is planning to add support for marking the
outermost frame. That would be one definitive way to know that the
stack trace made it to the end.
Or, if the entry-from-user pt_regs frame is always stored at a certain
offset compared to the end of the task stack page, that might be another
way.
--
Josh
^ permalink raw reply
* Re: [PATCH v2 0/6] unwind, arm64: add sframe unwinder for kernel
From: Dylan Hatch @ 2025-11-15 6:50 UTC (permalink / raw)
To: Puranjay Mohan
Cc: Song Liu, Josh Poimboeuf, Steven Rostedt, Indu Bhagat,
Peter Zijlstra, Will Deacon, Catalin Marinas, Jiri Kosina,
Roman Gushchin, Weinan Liu, Mark Rutland, Ian Rogers,
linux-toolchains, linux-kernel, live-patching, joe.lawrence,
Puranjay Mohan
In-Reply-To: <CANk7y0hUKOVXRKoJ5Ufmg-5DGSe2F5nBH+O7tLVvLRs9Oe54uA@mail.gmail.com>
On Mon, Sep 29, 2025 at 12:55 PM Puranjay Mohan <puranjay12@gmail.com> wrote:
>
> I will try to debug this more but am just curious about BPF's
> interactions with sframe.
> The sframe data for bpf programs doesn't exist, so we would need to
> add that support
> and that wouldn't be trivial, given the BPF programs are JITed.
>
> Thanks,
> Puranjay
From what I can tell, the ORC unwinder in x86 falls back to using
frame pointers in cases of generated code, like BPF. Would matching
this behavior in the sframe unwinder be a reasonable approach, at
least for the purposes of enabling reliable unwind for livepatch?
Thanks,
Dylan
^ permalink raw reply
* Re: [PATCH v2 6/6] unwind: arm64: Add reliable stacktrace with sframe unwinder.
From: Dylan Hatch @ 2025-11-15 6:44 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Steven Rostedt, Indu Bhagat, Peter Zijlstra, Will Deacon,
Catalin Marinas, Jiri Kosina, Roman Gushchin, Weinan Liu,
Mark Rutland, Ian Rogers, linux-toolchains, linux-kernel,
live-patching, joe.lawrence, Puranjay Mohan, Song Liu,
Prasanna Kumar T S M
In-Reply-To: <xo2ro446awhsd7i55shx6tlz6s2azuown4xk6zfm7ie4zz2nqc@244onpurkvy3>
Sorry for the slow reply on this, I'm going to try and get a v3 out
sometime after next week.
On Wed, Sep 17, 2025 at 4:41 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> As far I can tell, the *only* error condition being checked is if it
> (successfully) fell back to frame pointers.
By checking/handling error conditions, do you mean just marking the
state as unreliable in any case where the unwind isn't successful with
SFrame? I'm thinking if I can make the unwind_next_frame_sframe() code
path handle the end of the stack correctly on its own, I can more
strictly mark the trace as unreliable if it encounters any error.
>
> What if there was some bad or missing sframe data? Or some unexpected
> condition on the stack?
>
> Also, does the exception handling code have correct cfi/sframe metadata?
>
> In order for it to be "reliable", we need to know the unwind reached the
> end of the stack (e.g., the task pt_regs frame, from entry-from-user).
It looks like the frame-pointer based method of handling the end of
the stack involves calling kunwind_next_frame_record_meta() to extract
and check frame_record_meta::type for FRAME_META_TYPE_FINAL. I think
this currently assumes (based on the definition of 'struct
frame_record') that the next FP and PC are right next to each other,
alongside the meta type. But the sframe format stores separate entries
for the FP and RA offsets, which makes extracting the meta type from
this information a little bit murky to me.
Would it make sense to fall back to the frame pointer method for the
final stack frame? Or I guess I could define a new sframe-friendly
meta frame record format?
Thanks,
Dylan
^ permalink raw reply
* Re: [PATCH 2/4] media: atomisp: Fix startup() section placement with -ffunction-sections
From: Josh Poimboeuf @ 2025-11-14 20:43 UTC (permalink / raw)
To: Peter Zijlstra
Cc: x86, linux-kernel, live-patching, Hans de Goede,
Mauro Carvalho Chehab, linux-toolchains
In-Reply-To: <20251114085657.GR278048@noisy.programming.kicks-ass.net>
On Fri, Nov 14, 2025 at 09:56:57AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 12, 2025 at 03:47:49PM -0800, Josh Poimboeuf wrote:
> > When compiling the kernel with -ffunction-sections (e.g., for LTO,
> > livepatch, dead code elimination, AutoFDO, or Propeller), the startup()
> > function gets compiled into the .text.startup section. In some cases it
> > can even be cloned into .text.startup.constprop.0 or
> > .text.startup.isra.0.
> >
> > However, the .text.startup and .text.startup.* section names are already
> > reserved for use by the compiler for __attribute__((constructor)) code.
> >
>
> Urgh, that's a 'fun' one. Is this not a -ffunction-sections bug? I mean,
> the compiler should never put regular non-reserved user symbols in a
> section it has reserved for itself, right?
Right, so there's no ambiguity *IF* we know in advance whether it was
compiled with -ffunction-sections. If so, constructor code goes in
.text.startup.*, and startup() goes in .text.startup or
.text.startup.constprop.0 or .text.startup.isra.0.
So it's not really a compiler bug because it's possible to disambiguate
those.
Problem is, we can have some objects compiled with -ffunction-sections,
and some compiled without, in the same kernel. So the disambiguation
isn't possible at link time, since for example .text.startup could be
startup() with -ffunction-sections, or it could be
__attribute__((constructor)) without -ffunction-sections.
I attempted to describe all that in patch 4.
--
Josh
^ permalink raw reply
* Re: [PATCH v2 1/6] unwind: build kernel with sframe info
From: Will Deacon @ 2025-11-14 13:34 UTC (permalink / raw)
To: Dylan Hatch
Cc: Josh Poimboeuf, Steven Rostedt, Indu Bhagat, Peter Zijlstra,
Catalin Marinas, Jiri Kosina, Roman Gushchin, Weinan Liu,
Mark Rutland, Ian Rogers, linux-toolchains, linux-kernel,
live-patching, joe.lawrence, Puranjay Mohan, Song Liu,
Prasanna Kumar T S M
In-Reply-To: <20250904223850.884188-2-dylanbhatch@google.com>
On Thu, Sep 04, 2025 at 10:38:45PM +0000, Dylan Hatch wrote:
> Use the -Wa,--gsframe flags to build the code, so GAS will generate
> a new .sframe section for the stack trace information.
> Currently, the sframe format only supports arm64 and x86_64
> architectures. Add this configuration on arm64 to enable sframe
> unwinder in the future.
>
> Signed-off-by: Weinan Liu <wnliu@google.com>
> Signed-off-by: Dylan Hatch <dylanbhatch@google.com>
> Reviewed-by: Prasanna Kumar T S M <ptsm@linux.microsoft.com>
> ---
> Makefile | 8 ++++++++
> arch/Kconfig | 6 ++++++
> arch/arm64/Kconfig.debug | 10 ++++++++++
> arch/arm64/kernel/vdso/Makefile | 2 +-
> include/asm-generic/vmlinux.lds.h | 15 +++++++++++++++
> 5 files changed, 40 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index b9c661913250..09972c71a3e8 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1078,6 +1078,14 @@ endif
> # Ensure compilers do not transform certain loops into calls to wcslen()
> KBUILD_CFLAGS += -fno-builtin-wcslen
>
> +# build with sframe table
> +ifdef CONFIG_SFRAME_UNWIND_TABLE
> +CC_FLAGS_SFRAME := -Wa,--gsframe
> +KBUILD_CFLAGS += $(CC_FLAGS_SFRAME)
> +KBUILD_AFLAGS += $(CC_FLAGS_SFRAME)
> +export CC_FLAGS_SFRAME
> +endif
> +
> # change __FILE__ to the relative path to the source directory
> ifdef building_out_of_srctree
> KBUILD_CPPFLAGS += $(call cc-option,-fmacro-prefix-map=$(srcroot)/=)
> diff --git a/arch/Kconfig b/arch/Kconfig
> index d1b4ffd6e085..4362d2f49d91 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -1782,4 +1782,10 @@ config ARCH_WANTS_PRE_LINK_VMLINUX
> config ARCH_HAS_CPU_ATTACK_VECTORS
> bool
>
> +config AS_SFRAME
> + def_bool $(as-instr,.cfi_sections .sframe\n.cfi_startproc\n.cfi_endproc)
Is it possible to extend this check so that we reject assemblers that
emit the unsupported "sframe version one" format?
> +config SFRAME_UNWIND_TABLE
> + bool
Is this extra option actually needed for anything?
> endmenu
> diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
> index 265c4461031f..d64bf58457de 100644
> --- a/arch/arm64/Kconfig.debug
> +++ b/arch/arm64/Kconfig.debug
> @@ -20,4 +20,14 @@ config ARM64_RELOC_TEST
> depends on m
> tristate "Relocation testing module"
>
> +config SFRAME_UNWINDER
> + bool "Sframe unwinder"
> + depends on AS_SFRAME
> + depends on 64BIT
Shouldn't there be an arch dependency here as well? Since architectures
need to make use of sframe in their unwinders, I was expecting something
like 'depends on ARCH_SUPPORTS_SFRAME_UNWINDER' here.
Will
^ permalink raw reply
* Re: [PATCH 2/4] media: atomisp: Fix startup() section placement with -ffunction-sections
From: Peter Zijlstra @ 2025-11-14 8:56 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: x86, linux-kernel, live-patching, Hans de Goede,
Mauro Carvalho Chehab, linux-toolchains
In-Reply-To: <bf8cd823a3f11f64cc82167913be5013c72afa57.1762991150.git.jpoimboe@kernel.org>
On Wed, Nov 12, 2025 at 03:47:49PM -0800, Josh Poimboeuf wrote:
> When compiling the kernel with -ffunction-sections (e.g., for LTO,
> livepatch, dead code elimination, AutoFDO, or Propeller), the startup()
> function gets compiled into the .text.startup section. In some cases it
> can even be cloned into .text.startup.constprop.0 or
> .text.startup.isra.0.
>
> However, the .text.startup and .text.startup.* section names are already
> reserved for use by the compiler for __attribute__((constructor)) code.
>
Urgh, that's a 'fun' one. Is this not a -ffunction-sections bug? I mean,
the compiler should never put regular non-reserved user symbols in a
section it has reserved for itself, right?
^ permalink raw reply
* [tip: objtool/core] vmlinux.lds: Fix TEXT_MAIN to include .text.start and friends
From: tip-bot2 for Josh Poimboeuf @ 2025-11-13 7:08 UTC (permalink / raw)
To: linux-tip-commits
Cc: kernel test robot, Josh Poimboeuf, Ingo Molnar, Peter Zijlstra,
live-patching, Linus Torvalds, x86, linux-kernel
In-Reply-To: <cd588144e63df901a656b06b566855019c4a931d.1762991150.git.jpoimboe@kernel.org>
The following commit has been merged into the objtool/core branch of tip:
Commit-ID: f6a8919d61484ae9ca6b1855035fcfb2ba6e2af9
Gitweb: https://git.kernel.org/tip/f6a8919d61484ae9ca6b1855035fcfb2ba6e2af9
Author: Josh Poimboeuf <jpoimboe@kernel.org>
AuthorDate: Wed, 12 Nov 2025 15:47:48 -08:00
Committer: Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 13 Nov 2025 08:03:09 +01:00
vmlinux.lds: Fix TEXT_MAIN to include .text.start and friends
Since:
6568f14cb5ae ("vmlinux.lds: Exclude .text.startup and .text.exit from TEXT_MAIN")
the TEXT_MAIN macro uses a series of patterns to prevent the
.text.startup[.*] and .text.exit[.*] sections from getting
linked into the vmlinux runtime .text.
That commit is a tad too aggressive: it also inadvertently filters out
valid runtime text sections like .text.start and
.text.start.constprop.0, which can be generated for a function named
start() when -ffunction-sections is enabled.
As a result, those sections become orphans when building with
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION for arm:
arm-linux-gnueabi-ld: warning: orphan section `.text.start.constprop.0' from `drivers/usb/host/sl811-hcd.o' being placed in section `.text.start.constprop.0'
arm-linux-gnueabi-ld: warning: orphan section `.text.start.constprop.0' from `drivers/media/dvb-frontends/drxk_hard.o' being placed in section `.text.start.constprop.0'
arm-linux-gnueabi-ld: warning: orphan section `.text.start' from `drivers/media/dvb-frontends/stv0910.o' being placed in section `.text.start'
arm-linux-gnueabi-ld: warning: orphan section `.text.start.constprop.0' from `drivers/media/pci/ddbridge/ddbridge-sx8.o' being placed in section `.text.start.constprop.0'
Fix that by explicitly adding the partial "substring" sections (.text.s,
.text.st, .text.sta, etc) and their cloned derivatives.
While this unfortunately means that TEXT_MAIN continues to grow,
these changes are ultimately necessary for proper support of
-ffunction-sections.
Fixes: 6568f14cb5ae ("vmlinux.lds: Exclude .text.startup and .text.exit from TEXT_MAIN")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: live-patching@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://patch.msgid.link/cd588144e63df901a656b06b566855019c4a931d.1762991150.git.jpoimboe@kernel.org
Closes: https://lore.kernel.org/oe-kbuild-all/202511040812.DFGedJiy-lkp@intel.com/
---
include/asm-generic/vmlinux.lds.h | 23 ++++++++++++-----------
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index cc060ad..8f92d66 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -90,8 +90,9 @@
* Support -ffunction-sections by matching .text and .text.*,
* but exclude '.text..*', .text.startup[.*], and .text.exit[.*].
*
- * .text.startup and .text.startup.* are matched later by INIT_TEXT.
- * .text.exit and .text.exit.* are matched later by EXIT_TEXT.
+ * .text.startup and .text.startup.* are matched later by INIT_TEXT, and
+ * .text.exit and .text.exit.* are matched later by EXIT_TEXT, so they must be
+ * explicitly excluded here.
*
* Other .text.* sections that are typically grouped separately, such as
* .text.unlikely or .text.hot, must be matched explicitly before using
@@ -100,16 +101,16 @@
#define TEXT_MAIN \
.text \
.text.[_0-9A-Za-df-rt-z]* \
- .text.s[_0-9A-Za-su-z]* \
- .text.st[_0-9A-Zb-z]* \
- .text.sta[_0-9A-Za-qs-z]* \
- .text.star[_0-9A-Za-su-z]* \
- .text.start[_0-9A-Za-tv-z]* \
- .text.startu[_0-9A-Za-oq-z]* \
+ .text.s[_0-9A-Za-su-z]* .text.s .text.s.* \
+ .text.st[_0-9A-Zb-z]* .text.st .text.st.* \
+ .text.sta[_0-9A-Za-qs-z]* .text.sta .text.sta.* \
+ .text.star[_0-9A-Za-su-z]* .text.star .text.star.* \
+ .text.start[_0-9A-Za-tv-z]* .text.start .text.start.* \
+ .text.startu[_0-9A-Za-oq-z]* .text.startu .text.startu.* \
.text.startup[_0-9A-Za-z]* \
- .text.e[_0-9A-Za-wy-z]* \
- .text.ex[_0-9A-Za-hj-z]* \
- .text.exi[_0-9A-Za-su-z]* \
+ .text.e[_0-9A-Za-wy-z]* .text.e .text.e.* \
+ .text.ex[_0-9A-Za-hj-z]* .text.ex .text.ex.* \
+ .text.exi[_0-9A-Za-su-z]* .text.exi .text.exi.* \
.text.exit[_0-9A-Za-z]*
/*
^ permalink raw reply related
* [tip: objtool/core] media: atomisp: Fix namespace collision and startup() section placement with -ffunction-sections
From: tip-bot2 for Josh Poimboeuf @ 2025-11-13 7:08 UTC (permalink / raw)
To: linux-tip-commits
Cc: Josh Poimboeuf, Ingo Molnar, Peter Zijlstra, live-patching,
Hans de Goede, Mauro Carvalho Chehab, Linus Torvalds, x86,
linux-kernel
In-Reply-To: <bf8cd823a3f11f64cc82167913be5013c72afa57.1762991150.git.jpoimboe@kernel.org>
The following commit has been merged into the objtool/core branch of tip:
Commit-ID: 56255fa96871d3bd0d924a53585cdf5594262891
Gitweb: https://git.kernel.org/tip/56255fa96871d3bd0d924a53585cdf5594262891
Author: Josh Poimboeuf <jpoimboe@kernel.org>
AuthorDate: Wed, 12 Nov 2025 15:47:49 -08:00
Committer: Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 13 Nov 2025 08:03:09 +01:00
media: atomisp: Fix namespace collision and startup() section placement with -ffunction-sections
When compiling the kernel with -ffunction-sections (e.g., for LTO,
livepatch, dead code elimination, AutoFDO, or Propeller), the startup()
function gets compiled into the .text.startup section. In some cases it
can even be cloned into .text.startup.constprop.0 or
.text.startup.isra.0.
However, the .text.startup and .text.startup.* section names are already
reserved for use by the compiler for __attribute__((constructor)) code.
This naming conflict causes the vmlinux linker script to wrongly place
startup() function code in .init.text, which gets freed during boot.
Fix that by renaming startup() to ov2722_startup().
Fixes: 6568f14cb5ae ("vmlinux.lds: Exclude .text.startup and .text.exit from TEXT_MAIN")
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: live-patching@vger.kernel.org
Cc: Hans de Goede <hansg@kernel.org>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://patch.msgid.link/bf8cd823a3f11f64cc82167913be5013c72afa57.1762991150.git.jpoimboe@kernel.org
---
drivers/staging/media/atomisp/i2c/atomisp-ov2722.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c b/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
index c7de780..a4519ba 100644
--- a/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
+++ b/drivers/staging/media/atomisp/i2c/atomisp-ov2722.c
@@ -600,7 +600,7 @@ static int ov2722_s_power(struct v4l2_subdev *sd, int on)
}
/* TODO: remove it. */
-static int startup(struct v4l2_subdev *sd)
+static int ov2722_startup(struct v4l2_subdev *sd)
{
struct ov2722_device *dev = to_ov2722_sensor(sd);
struct i2c_client *client = v4l2_get_subdevdata(sd);
@@ -662,7 +662,7 @@ static int ov2722_set_fmt(struct v4l2_subdev *sd,
dev->pixels_per_line = dev->res->pixels_per_line;
dev->lines_per_frame = dev->res->lines_per_frame;
- ret = startup(sd);
+ ret = ov2722_startup(sd);
if (ret) {
int i = 0;
@@ -677,7 +677,7 @@ static int ov2722_set_fmt(struct v4l2_subdev *sd,
dev_err(&client->dev, "power up failed, continue\n");
continue;
}
- ret = startup(sd);
+ ret = ov2722_startup(sd);
if (ret) {
dev_err(&client->dev, " startup FAILED!\n");
} else {
^ permalink raw reply related
* [tip: objtool/core] drivers/xen/xenbus: Fix namespace collision and split() section placement with AutoFDO
From: tip-bot2 for Josh Poimboeuf @ 2025-11-13 7:08 UTC (permalink / raw)
To: linux-tip-commits
Cc: Josh Poimboeuf, Ingo Molnar, Peter Zijlstra, live-patching,
Juergen Gross, Linus Torvalds, x86, linux-kernel
In-Reply-To: <92a194234a0f757765e275b288bb1a7236c2c35c.1762991150.git.jpoimboe@kernel.org>
The following commit has been merged into the objtool/core branch of tip:
Commit-ID: 0330b7fbbf313b35470306a492b9e7a703b5af56
Gitweb: https://git.kernel.org/tip/0330b7fbbf313b35470306a492b9e7a703b5af56
Author: Josh Poimboeuf <jpoimboe@kernel.org>
AuthorDate: Wed, 12 Nov 2025 15:47:50 -08:00
Committer: Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 13 Nov 2025 08:03:10 +01:00
drivers/xen/xenbus: Fix namespace collision and split() section placement with AutoFDO
When compiling the kernel with -ffunction-sections enabled, the split()
function gets compiled into the .text.split section. In some cases it
can even be cloned into .text.split.constprop.0 or .text.split.isra.0.
However, .text.split.* is already reserved for use by the Clang
-fsplit-machine-functions flag, which is used by AutoFDO. That may
place part of a function's code in a .text.split.<func> section.
This naming conflict causes the vmlinux linker script to wrongly place
split() with other .text.split.* code, rather than where it belongs with
regular text.
Fix it by renaming split() to split_strings().
Fixes: 6568f14cb5ae ("vmlinux.lds: Exclude .text.startup and .text.exit from TEXT_MAIN")
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: live-patching@vger.kernel.org
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://patch.msgid.link/92a194234a0f757765e275b288bb1a7236c2c35c.1762991150.git.jpoimboe@kernel.org
---
drivers/xen/xenbus/xenbus_xs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/xen/xenbus/xenbus_xs.c b/drivers/xen/xenbus/xenbus_xs.c
index 528682b..f794014 100644
--- a/drivers/xen/xenbus/xenbus_xs.c
+++ b/drivers/xen/xenbus/xenbus_xs.c
@@ -410,7 +410,7 @@ static char *join(const char *dir, const char *name)
return (!buffer) ? ERR_PTR(-ENOMEM) : buffer;
}
-static char **split(char *strings, unsigned int len, unsigned int *num)
+static char **split_strings(char *strings, unsigned int len, unsigned int *num)
{
char *p, **ret;
@@ -448,7 +448,7 @@ char **xenbus_directory(struct xenbus_transaction t,
if (IS_ERR(strings))
return ERR_CAST(strings);
- return split(strings, len, num);
+ return split_strings(strings, len, num);
}
EXPORT_SYMBOL_GPL(xenbus_directory);
^ permalink raw reply related
* [tip: objtool/core] objtool: Warn on functions with ambiguous -ffunction-sections section names
From: tip-bot2 for Josh Poimboeuf @ 2025-11-13 7:08 UTC (permalink / raw)
To: linux-tip-commits
Cc: Josh Poimboeuf, Ingo Molnar, Peter Zijlstra, live-patching,
Linus Torvalds, x86, linux-kernel
In-Reply-To: <65fedea974fe14be487c8867a0b8d0e4a294ce1e.1762991150.git.jpoimboe@kernel.org>
The following commit has been merged into the objtool/core branch of tip:
Commit-ID: 9c7dc1dd897a1cdcade9566ea4664b03fbabf4a4
Gitweb: https://git.kernel.org/tip/9c7dc1dd897a1cdcade9566ea4664b03fbabf4a4
Author: Josh Poimboeuf <jpoimboe@kernel.org>
AuthorDate: Wed, 12 Nov 2025 15:47:51 -08:00
Committer: Ingo Molnar <mingo@kernel.org>
CommitterDate: Thu, 13 Nov 2025 08:03:10 +01:00
objtool: Warn on functions with ambiguous -ffunction-sections section names
When compiled with -ffunction-sections, a function named startup() will
be placed in .text.startup. However, .text.startup is also used by the
compiler for functions with __attribute__((constructor)).
That creates an ambiguity for the vmlinux linker script, which needs to
differentiate those two cases.
Similar naming conflicts exist for functions named exit(), split(),
unlikely(), hot() and unknown().
One potential solution would be to use '#ifdef CC_USING_FUNCTION_SECTIONS'
to create two distinct implementations of the TEXT_MAIN macro. However,
-ffunction-sections can be (and is) enabled or disabled on a per-object
basis (for example via ccflags-y or AUTOFDO_PROFILE).
So the recently unified TEXT_MAIN macro (commit 1ba9f8979426
("vmlinux.lds: Unify TEXT_MAIN, DATA_MAIN, and related macros")) is
necessary. This means there's no way for the linker script to
disambiguate things.
Instead, use objtool to warn on any function names whose resulting
section names might create ambiguity when the kernel is compiled (in
whole or in part) with -ffunction-sections.
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: live-patching@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://patch.msgid.link/65fedea974fe14be487c8867a0b8d0e4a294ce1e.1762991150.git.jpoimboe@kernel.org
---
include/asm-generic/vmlinux.lds.h | 15 +++++++++++-
tools/objtool/Documentation/objtool.txt | 7 +++++-
tools/objtool/check.c | 33 ++++++++++++++++++++++++-
3 files changed, 55 insertions(+)
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 8f92d66..5efe1de 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -97,6 +97,21 @@
* Other .text.* sections that are typically grouped separately, such as
* .text.unlikely or .text.hot, must be matched explicitly before using
* TEXT_MAIN.
+ *
+ * NOTE: builds *with* and *without* -ffunction-sections are both supported by
+ * this single macro. Even with -ffunction-sections, there may be some objects
+ * NOT compiled with the flag due to the use of a specific Makefile override
+ * like cflags-y or AUTOFDO_PROFILE_foo.o. So this single catchall rule is
+ * needed to support mixed object builds.
+ *
+ * One implication is that functions named startup(), exit(), split(),
+ * unlikely(), hot(), and unknown() are not allowed in the kernel due to the
+ * ambiguity of their section names with -ffunction-sections. For example,
+ * .text.startup could be __attribute__((constructor)) code in a *non*
+ * ffunction-sections object, which should be placed in .init.text; or it could
+ * be an actual function named startup() in an ffunction-sections object, which
+ * should be placed in .text. Objtool will detect and complain about any such
+ * ambiguously named functions.
*/
#define TEXT_MAIN \
.text \
diff --git a/tools/objtool/Documentation/objtool.txt b/tools/objtool/Documentation/objtool.txt
index 9e97fc2..f88f8d2 100644
--- a/tools/objtool/Documentation/objtool.txt
+++ b/tools/objtool/Documentation/objtool.txt
@@ -456,6 +456,13 @@ the objtool maintainers.
these special names and does not use module_init() / module_exit()
macros to create them.
+13. file.o: warning: func() function name creates ambiguity with -ffunctions-sections
+
+ Functions named startup(), exit(), split(), unlikely(), hot(), and
+ unknown() are not allowed due to the ambiguity of their section
+ names when compiled with -ffunction-sections. For more information,
+ see the comment above TEXT_MAIN in include/asm-generic/vmlinux.lds.h.
+
If the error doesn't seem to make sense, it could be a bug in objtool.
Feel free to ask objtool maintainers for help.
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 57fac6c..72c7f6f 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -2663,6 +2663,37 @@ static int decode_sections(struct objtool_file *file)
return 0;
}
+/*
+ * Certain function names are disallowed due to section name ambiguities
+ * introduced by -ffunction-sections.
+ *
+ * See the comment above TEXT_MAIN in include/asm-generic/vmlinux.lds.h.
+ */
+static int validate_function_names(struct objtool_file *file)
+{
+ struct symbol *func;
+ int warnings = 0;
+
+ for_each_sym(file->elf, func) {
+ if (!is_func_sym(func))
+ continue;
+
+ if (!strcmp(func->name, "startup") || strstarts(func->name, "startup.") ||
+ !strcmp(func->name, "exit") || strstarts(func->name, "exit.") ||
+ !strcmp(func->name, "split") || strstarts(func->name, "split.") ||
+ !strcmp(func->name, "unlikely") || strstarts(func->name, "unlikely.") ||
+ !strcmp(func->name, "hot") || strstarts(func->name, "hot.") ||
+ !strcmp(func->name, "unknown") || strstarts(func->name, "unknown.")) {
+
+ WARN("%s() function name creates ambiguity with -ffunction-sections",
+ func->name);
+ warnings++;
+ }
+ }
+
+ return warnings;
+}
+
static bool is_special_call(struct instruction *insn)
{
if (insn->type == INSN_CALL) {
@@ -4932,6 +4963,8 @@ int check(struct objtool_file *file)
if (!nr_insns)
goto out;
+ warnings += validate_function_names(file);
+
if (opts.retpoline)
warnings += validate_retpoline(file);
^ permalink raw reply related
* RE: [PATCH 2/2] objtool/klp: Only enable --checksum when needed
From: Michael Kelley @ 2025-11-13 2:29 UTC (permalink / raw)
To: Josh Poimboeuf, x86@kernel.org
Cc: linux-kernel@vger.kernel.org, Peter Zijlstra,
live-patching@vger.kernel.org
In-Reply-To: <edbb1ca215e4926e02edb493b68b9d6d063e902f.1762990139.git.jpoimboe@kernel.org>
From: Josh Poimboeuf <jpoimboe@kernel.org> Sent: Wednesday, November 12, 2025 3:33 PM
>
> With CONFIG_KLP_BUILD enabled, checksums are only needed during a
> klp-build run. There's no need to enable them for normal kernel builds.
>
> This also has the benefit of softening the xxhash dependency.
>
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> ---
> arch/x86/boot/startup/Makefile | 2 +-
> scripts/Makefile.lib | 1 -
> scripts/livepatch/klp-build | 4 ++++
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/boot/startup/Makefile b/arch/x86/boot/startup/Makefile
> index e8fdf020b422..5e499cfb29b5 100644
> --- a/arch/x86/boot/startup/Makefile
> +++ b/arch/x86/boot/startup/Makefile
> @@ -36,7 +36,7 @@ $(patsubst %.o,$(obj)/%.o,$(lib-y)):
> OBJECT_FILES_NON_STANDARD := y
> # relocations, even if other objtool actions are being deferred.
> #
> $(pi-objs): objtool-enabled = 1
> -$(pi-objs): objtool-args = $(if $(delay-objtool),,$(objtool-args-y)) --noabs
> +$(pi-objs): objtool-args = $(if $(delay-objtool),--dry-run,$(objtool-args-y)) --noabs
>
> #
> # Confine the startup code by prefixing all symbols with __pi_ (for position
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index f4b33919ec37..28a1c08e3b22 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -173,7 +173,6 @@ ifdef CONFIG_OBJTOOL
>
> objtool := $(objtree)/tools/objtool/objtool
>
> -objtool-args-$(CONFIG_KLP_BUILD) += --checksum
> objtool-args-$(CONFIG_HAVE_JUMP_LABEL_HACK) += --hacks=jump_label
> objtool-args-$(CONFIG_HAVE_NOINSTR_HACK) += --hacks=noinstr
> objtool-args-$(CONFIG_MITIGATION_CALL_DEPTH_TRACKING) += --hacks=skylake
> diff --git a/scripts/livepatch/klp-build b/scripts/livepatch/klp-build
> index 881e052e7fae..882272120c9e 100755
> --- a/scripts/livepatch/klp-build
> +++ b/scripts/livepatch/klp-build
> @@ -489,8 +489,11 @@ clean_kernel() {
>
> build_kernel() {
> local log="$TMP_DIR/build.log"
> + local objtool_args=()
> local cmd=()
>
> + objtool_args=("--checksum")
> +
> cmd=("make")
>
> # When a patch to a kernel module references a newly created unexported
> @@ -513,6 +516,7 @@ build_kernel() {
> cmd+=("$VERBOSE")
> cmd+=("-j$JOBS")
> cmd+=("KCFLAGS=-ffunction-sections -fdata-sections")
> + cmd+=("OBJTOOL_ARGS=${objtool_args[*]}")
> cmd+=("vmlinux")
> cmd+=("modules")
>
> --
> 2.51.1
Did a normal linux-next kernel build on an Ubuntu 20.04 system, which by default
does not have xxhash installed. Previous error about needing to install libxxhash-dev
is no longer generated. Have not tested a klp-build.
Tested-by: Michael Kelley <mhklinux@outlook.com>
^ permalink raw reply
* RE: [PATCH 1/2] objtool: Set minimum xxhash version to 0.8
From: Michael Kelley @ 2025-11-13 2:25 UTC (permalink / raw)
To: Josh Poimboeuf, x86@kernel.org
Cc: linux-kernel@vger.kernel.org, Peter Zijlstra,
live-patching@vger.kernel.org
In-Reply-To: <7227c94692a3a51840278744c7af31b4797c6b96.1762990139.git.jpoimboe@kernel.org>
From: Josh Poimboeuf <jpoimboe@kernel.org> Sent: Wednesday, November 12, 2025 3:33 PM
>
> XXH3 is only supported starting with xxhash 0.8. Enforce that.
>
> Fixes: 0d83da43b1e1 ("objtool/klp: Add --checksum option to generate per-function checksums")
> Reported-by: Michael Kelley <mhklinux@outlook.com>
> Closes: https://lore.kernel.org/all/SN6PR02MB41579B83CD295C9FEE40EED6D4FCA@SN6PR02MB4157.namprd02.prod.outlook.com
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> ---
> tools/objtool/Makefile | 2 +-
> tools/objtool/builtin-check.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
> index 48928c9bebef..021f55b7bd87 100644
> --- a/tools/objtool/Makefile
> +++ b/tools/objtool/Makefile
> @@ -12,7 +12,7 @@ ifeq ($(SRCARCH),loongarch)
> endif
>
> ifeq ($(ARCH_HAS_KLP),y)
> - HAVE_XXHASH = $(shell echo "int main() {}" | \
> + HAVE_XXHASH = $(shell printf "$(pound)include <xxhash.h>\nXXH3_state_t *state;int main() {}" | \
> $(HOSTCC) -xc - -o /dev/null -lxxhash 2> /dev/null && echo y || echo n)
> ifeq ($(HAVE_XXHASH),y)
> BUILD_KLP := y
> diff --git a/tools/objtool/builtin-check.c b/tools/objtool/builtin-check.c
> index 1e1ea8396eb3..aab7fa9c7e00 100644
> --- a/tools/objtool/builtin-check.c
> +++ b/tools/objtool/builtin-check.c
> @@ -164,7 +164,7 @@ static bool opts_valid(void)
>
> #ifndef BUILD_KLP
> if (opts.checksum) {
> - ERROR("--checksum not supported; install xxhash-devel/libxxhash-dev and recompile");
> + ERROR("--checksum not supported; install xxhash-devel/libxxhash-dev (version >= 0.8) and recompile");
> return false;
> }
> #endif
> --
> 2.51.1
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
^ 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