Re: [PATCH v2 11/13] x86/entry/fred: encode frame pointer on entry

[H. Peter Anvin]

On May 20, 2026 3:24:57 PM PDT, David Stevens <stevensd@xxxxxxxxxx> wrote:
>Setting aside the rest of the RFC, should this patch be merged? If
>someone tries to use CONFIG_UNWINDER_FRAME_POINTER on a system with
>FRED, they'll get a "kernel stack regs ... has bad 'bp' value" warning
>in the logs the first time the unwinder runs.
>
>Thanks,
>David
>
>On Fri, Apr 24, 2026 at 12:17 PM David Stevens <stevensd@xxxxxxxxxx> wrote:
>>
>> Add missing ENCODE_FRAME_POINTER macro invocation into FRED_ENTER macro,
>> to prevent the unwinder from encountering a NULL stack frame pointer
>> when CONFIG_UNWINDER_FRAME_POINTER is enabled
>>
>> Fixes: 14619d912b65 ("x86/fred: FRED entry/exit and dispatch code")
>> Signed-off-by: David Stevens <stevensd@xxxxxxxxxx>
>> ---
>>  arch/x86/entry/entry_64_fred.S | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/x86/entry/entry_64_fred.S b/arch/x86/entry/entry_64_fred.S
>> index 894f7f16eb80..119b8214748e 100644
>> --- a/arch/x86/entry/entry_64_fred.S
>> +++ b/arch/x86/entry/entry_64_fred.S
>> @@ -7,6 +7,7 @@
>>  #include <linux/kvm_types.h>
>>
>>  #include <asm/asm.h>
>> +#include <asm/frame.h>
>>  #include <asm/fred.h>
>>  #include <asm/segment.h>
>>
>> @@ -19,6 +20,7 @@
>>         UNWIND_HINT_END_OF_STACK
>>         ANNOTATE_NOENDBR
>>         PUSH_AND_CLEAR_REGS
>> +       ENCODE_FRAME_POINTER
>>         movq    %rsp, %rdi      /* %rdi -> pt_regs */
>>  .endm
>>
>> --
>> 2.54.0.rc2.544.gc7ae2d5bb8-goog
>>
>

Yes, it should.

The macroization is weird and I'm somewhat confused about how it is done but I also don't really care because it isn't like frame pointer use is common on x86-64.

Acked-by: H. Peter Anvin (Intel) <hpa@xxxxxxxxx>