From: James Morse <[email protected]>
commit b28a8eebe81c186fdb1a0078263b30576c8e1f42 upstream.
The trampoline code needs to use the address of symbols in the wider
kernel, e.g. vectors. PC-relative addressing wouldn't work as the
trampoline code doesn't run at the address the linker expected.
tramp_ventry uses a literal pool, unless CONFIG_RANDOMIZE_BASE is
set, in which case it uses the data page as a literal pool because
the data page can be unmapped when running in user-space, which is
required for CPUs vulnerable to meltdown.
Pull this logic out as a macro, instead of adding a third copy
of it.
Reviewed-by: Catalin Marinas <[email protected]>
Signed-off-by: James Morse <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
arch/arm64/kernel/entry.S | 35 ++++++++++++++++-------------------
1 file changed, 16 insertions(+), 19 deletions(-)
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 14351ee5e812..e4b5a15c2e2e 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -1063,6 +1063,15 @@ alternative_else_nop_endif
sub \dst, \dst, PAGE_SIZE
.endm
+ .macro tramp_data_read_var dst, var
+#ifdef CONFIG_RANDOMIZE_BASE
+ tramp_data_page \dst
+ add \dst, \dst, #:lo12:__entry_tramp_data_\var
+ ldr \dst, [\dst]
+#else
+ ldr \dst, =\var
+#endif
+ .endm
#define BHB_MITIGATION_NONE 0
#define BHB_MITIGATION_LOOP 1
@@ -1093,13 +1102,8 @@ alternative_else_nop_endif
b .
2:
tramp_map_kernel x30
-#ifdef CONFIG_RANDOMIZE_BASE
- tramp_data_page x30
alternative_insn isb, nop, ARM64_WORKAROUND_QCOM_FALKOR_E1003
- ldr x30, [x30]
-#else
- ldr x30, =vectors
-#endif
+ tramp_data_read_var x30, vectors
alternative_if_not ARM64_WORKAROUND_CAVIUM_TX2_219_PRFM
prfm plil1strm, [x30, #(1b - \vector_start)]
alternative_else_nop_endif
@@ -1183,7 +1187,12 @@ END(tramp_exit_compat)
.align PAGE_SHIFT
.globl __entry_tramp_data_start
__entry_tramp_data_start:
+__entry_tramp_data_vectors:
.quad vectors
+#ifdef CONFIG_ARM_SDE_INTERFACE
+__entry_tramp_data___sdei_asm_trampoline_next_handler:
+ .quad __sdei_asm_handler
+#endif /* CONFIG_ARM_SDE_INTERFACE */
.popsection // .rodata
#endif /* CONFIG_RANDOMIZE_BASE */
#endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
@@ -1310,13 +1319,7 @@ ENTRY(__sdei_asm_entry_trampoline)
*/
1: str x4, [x1, #(SDEI_EVENT_INTREGS + S_ORIG_ADDR_LIMIT)]
-#ifdef CONFIG_RANDOMIZE_BASE
- tramp_data_page x4
- add x4, x4, #:lo12:__sdei_asm_trampoline_next_handler
- ldr x4, [x4]
-#else
- ldr x4, =__sdei_asm_handler
-#endif
+ tramp_data_read_var x4, __sdei_asm_trampoline_next_handler
br x4
ENDPROC(__sdei_asm_entry_trampoline)
NOKPROBE(__sdei_asm_entry_trampoline)
@@ -1339,12 +1342,6 @@ ENDPROC(__sdei_asm_exit_trampoline)
NOKPROBE(__sdei_asm_exit_trampoline)
.ltorg
.popsection // .entry.tramp.text
-#ifdef CONFIG_RANDOMIZE_BASE
-.pushsection ".rodata", "a"
-__sdei_asm_trampoline_next_handler:
- .quad __sdei_asm_handler
-.popsection // .rodata
-#endif /* CONFIG_RANDOMIZE_BASE */
#endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
/*
--
2.34.1
On 3/17/22 5:45 AM, Greg Kroah-Hartman wrote:
> From: James Morse <[email protected]>
>
> commit b28a8eebe81c186fdb1a0078263b30576c8e1f42 upstream.
>
> The trampoline code needs to use the address of symbols in the wider
> kernel, e.g. vectors. PC-relative addressing wouldn't work as the
> trampoline code doesn't run at the address the linker expected.
>
> tramp_ventry uses a literal pool, unless CONFIG_RANDOMIZE_BASE is
> set, in which case it uses the data page as a literal pool because
> the data page can be unmapped when running in user-space, which is
> required for CPUs vulnerable to meltdown.
>
> Pull this logic out as a macro, instead of adding a third copy
> of it.
>
> Reviewed-by: Catalin Marinas <[email protected]>
> Signed-off-by: James Morse <[email protected]>
> Signed-off-by: Sasha Levin <[email protected]>
This commit causes a linking failure with CONFIG_ARM_SDE_INTERFACE=y
enabled in the kernel:
LD .tmp_vmlinux.kallsyms1
/local/users/fainelli/buildroot/output/arm64/host/bin/aarch64-linux-ld:
arch/arm64/kernel/entry.o: in function `__sdei_asm_exit_trampoline':
/local/users/fainelli/buildroot/output/arm64/build/linux-custom/arch/arm64/kernel/entry.S:1352:
undefined reference to `__sdei_asm_trampoline_next_handler'
make[2]: *** [Makefile:1100: vmlinux] Error 1
make[1]: *** [package/pkg-generic.mk:295:
/local/users/fainelli/buildroot/output/arm64/build/linux-custom/.stamp_built]
Error 2
make: *** [Makefile:27: _all] Error 2
> ---
> arch/arm64/kernel/entry.S | 35 ++++++++++++++++-------------------
> 1 file changed, 16 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index 14351ee5e812..e4b5a15c2e2e 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -1063,6 +1063,15 @@ alternative_else_nop_endif
> sub \dst, \dst, PAGE_SIZE
> .endm
>
> + .macro tramp_data_read_var dst, var
> +#ifdef CONFIG_RANDOMIZE_BASE
> + tramp_data_page \dst
> + add \dst, \dst, #:lo12:__entry_tramp_data_\var
> + ldr \dst, [\dst]
> +#else
> + ldr \dst, =\var
> +#endif
> + .endm
>
> #define BHB_MITIGATION_NONE 0
> #define BHB_MITIGATION_LOOP 1
> @@ -1093,13 +1102,8 @@ alternative_else_nop_endif
> b .
> 2:
> tramp_map_kernel x30
> -#ifdef CONFIG_RANDOMIZE_BASE
> - tramp_data_page x30
> alternative_insn isb, nop, ARM64_WORKAROUND_QCOM_FALKOR_E1003
> - ldr x30, [x30]
> -#else
> - ldr x30, =vectors
> -#endif
> + tramp_data_read_var x30, vectors
> alternative_if_not ARM64_WORKAROUND_CAVIUM_TX2_219_PRFM
> prfm plil1strm, [x30, #(1b - \vector_start)]
> alternative_else_nop_endif
> @@ -1183,7 +1187,12 @@ END(tramp_exit_compat)
> .align PAGE_SHIFT
> .globl __entry_tramp_data_start
> __entry_tramp_data_start:
> +__entry_tramp_data_vectors:
> .quad vectors
> +#ifdef CONFIG_ARM_SDE_INTERFACE
> +__entry_tramp_data___sdei_asm_trampoline_next_handler:
> + .quad __sdei_asm_handler
> +#endif /* CONFIG_ARM_SDE_INTERFACE */
> .popsection // .rodata
> #endif /* CONFIG_RANDOMIZE_BASE */
> #endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
> @@ -1310,13 +1319,7 @@ ENTRY(__sdei_asm_entry_trampoline)
> */
> 1: str x4, [x1, #(SDEI_EVENT_INTREGS + S_ORIG_ADDR_LIMIT)]
>
> -#ifdef CONFIG_RANDOMIZE_BASE
> - tramp_data_page x4
> - add x4, x4, #:lo12:__sdei_asm_trampoline_next_handler
> - ldr x4, [x4]
> -#else
> - ldr x4, =__sdei_asm_handler
> -#endif
> + tramp_data_read_var x4, __sdei_asm_trampoline_next_handler
> br x4
> ENDPROC(__sdei_asm_entry_trampoline)
> NOKPROBE(__sdei_asm_entry_trampoline)
> @@ -1339,12 +1342,6 @@ ENDPROC(__sdei_asm_exit_trampoline)
> NOKPROBE(__sdei_asm_exit_trampoline)
> .ltorg
> .popsection // .entry.tramp.text
> -#ifdef CONFIG_RANDOMIZE_BASE
> -.pushsection ".rodata", "a"
> -__sdei_asm_trampoline_next_handler:
> - .quad __sdei_asm_handler
> -.popsection // .rodata
> -#endif /* CONFIG_RANDOMIZE_BASE */
> #endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
>
> /*
>
--
Florian
Hi Florian,
On 3/17/22 8:48 PM, Florian Fainelli wrote:
> On 3/17/22 5:45 AM, Greg Kroah-Hartman wrote:
>> From: James Morse <[email protected]>
>>
>> commit b28a8eebe81c186fdb1a0078263b30576c8e1f42 upstream.
>>
>> The trampoline code needs to use the address of symbols in the wider
>> kernel, e.g. vectors. PC-relative addressing wouldn't work as the
>> trampoline code doesn't run at the address the linker expected.
>>
>> tramp_ventry uses a literal pool, unless CONFIG_RANDOMIZE_BASE is
>> set, in which case it uses the data page as a literal pool because
>> the data page can be unmapped when running in user-space, which is
>> required for CPUs vulnerable to meltdown.
>>
>> Pull this logic out as a macro, instead of adding a third copy
>> of it.
>>
>> Reviewed-by: Catalin Marinas <[email protected]>
>> Signed-off-by: James Morse <[email protected]>
>> Signed-off-by: Sasha Levin <[email protected]>
>
> This commit causes a linking failure with CONFIG_ARM_SDE_INTERFACE=y
> enabled in the kernel:
>
> LD .tmp_vmlinux.kallsyms1
> /local/users/fainelli/buildroot/output/arm64/host/bin/aarch64-linux-ld:
> arch/arm64/kernel/entry.o: in function `__sdei_asm_exit_trampoline':
> /local/users/fainelli/buildroot/output/arm64/build/linux-custom/arch/arm64/kernel/entry.S:1352:
> undefined reference to `__sdei_asm_trampoline_next_handler'
> make[2]: *** [Makefile:1100: vmlinux] Error 1
> make[1]: *** [package/pkg-generic.mk:295:
> /local/users/fainelli/buildroot/output/arm64/build/linux-custom/.stamp_built]
> Error 2
> make: *** [Makefile:27: _all] Error 2
... and with CONFIG_RANDOMIZE_BASE turned off, which is why allyesconfig didn't catch it.
This is because I kept the next_handler bit of the label when it conflicted, which isn't needed
because the __entry_tramp bit added by the macro serves the same purpose.
The below diff fixes it:
----------%<----------
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index e4b5a15c2e2e..cfc0bb6c49f7 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -1190,7 +1190,7 @@ __entry_tramp_data_start:
__entry_tramp_data_vectors:
.quad vectors
#ifdef CONFIG_ARM_SDE_INTERFACE
-__entry_tramp_data___sdei_asm_trampoline_next_handler:
+__entry_tramp_data___sdei_asm_handler:
.quad __sdei_asm_handler
#endif /* CONFIG_ARM_SDE_INTERFACE */
.popsection // .rodata
@@ -1319,7 +1319,7 @@ ENTRY(__sdei_asm_entry_trampoline)
*/
1: str x4, [x1, #(SDEI_EVENT_INTREGS + S_ORIG_ADDR_LIMIT)]
- tramp_data_read_var x4, __sdei_asm_trampoline_next_handler
+ tramp_data_read_var x4, __sdei_asm_handler
br x4
ENDPROC(__sdei_asm_entry_trampoline)
NOKPROBE(__sdei_asm_entry_trampoline)
----------%<----------
Good news - this didn't happen with v5.10.
I don't see this in v5.4.185 yet.
Greg/Sasha, what is least work for you?:
A new version of this patch,
A fixup on top of the series,
Reposting the series with this fixed.
Thanks for catching this!
James
On Fri, Mar 18, 2022 at 12:11:32PM +0000, James Morse wrote:
> Hi Florian,
>
> On 3/17/22 8:48 PM, Florian Fainelli wrote:
> > On 3/17/22 5:45 AM, Greg Kroah-Hartman wrote:
> > > From: James Morse <[email protected]>
> > >
> > > commit b28a8eebe81c186fdb1a0078263b30576c8e1f42 upstream.
> > >
> > > The trampoline code needs to use the address of symbols in the wider
> > > kernel, e.g. vectors. PC-relative addressing wouldn't work as the
> > > trampoline code doesn't run at the address the linker expected.
> > >
> > > tramp_ventry uses a literal pool, unless CONFIG_RANDOMIZE_BASE is
> > > set, in which case it uses the data page as a literal pool because
> > > the data page can be unmapped when running in user-space, which is
> > > required for CPUs vulnerable to meltdown.
> > >
> > > Pull this logic out as a macro, instead of adding a third copy
> > > of it.
> > >
> > > Reviewed-by: Catalin Marinas <[email protected]>
> > > Signed-off-by: James Morse <[email protected]>
> > > Signed-off-by: Sasha Levin <[email protected]>
> >
> > This commit causes a linking failure with CONFIG_ARM_SDE_INTERFACE=y
> > enabled in the kernel:
> >
> > LD .tmp_vmlinux.kallsyms1
> > /local/users/fainelli/buildroot/output/arm64/host/bin/aarch64-linux-ld:
> > arch/arm64/kernel/entry.o: in function `__sdei_asm_exit_trampoline':
> > /local/users/fainelli/buildroot/output/arm64/build/linux-custom/arch/arm64/kernel/entry.S:1352:
> > undefined reference to `__sdei_asm_trampoline_next_handler'
> > make[2]: *** [Makefile:1100: vmlinux] Error 1
> > make[1]: *** [package/pkg-generic.mk:295:
> > /local/users/fainelli/buildroot/output/arm64/build/linux-custom/.stamp_built]
> > Error 2
> > make: *** [Makefile:27: _all] Error 2
>
> ... and with CONFIG_RANDOMIZE_BASE turned off, which is why allyesconfig didn't catch it.
> This is because I kept the next_handler bit of the label when it conflicted, which isn't needed
> because the __entry_tramp bit added by the macro serves the same purpose.
>
> The below diff fixes it:
> ----------%<----------
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index e4b5a15c2e2e..cfc0bb6c49f7 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -1190,7 +1190,7 @@ __entry_tramp_data_start:
> __entry_tramp_data_vectors:
> .quad vectors
> #ifdef CONFIG_ARM_SDE_INTERFACE
> -__entry_tramp_data___sdei_asm_trampoline_next_handler:
> +__entry_tramp_data___sdei_asm_handler:
> .quad __sdei_asm_handler
> #endif /* CONFIG_ARM_SDE_INTERFACE */
> .popsection // .rodata
> @@ -1319,7 +1319,7 @@ ENTRY(__sdei_asm_entry_trampoline)
> */
> 1: str x4, [x1, #(SDEI_EVENT_INTREGS + S_ORIG_ADDR_LIMIT)]
> - tramp_data_read_var x4, __sdei_asm_trampoline_next_handler
> + tramp_data_read_var x4, __sdei_asm_handler
> br x4
> ENDPROC(__sdei_asm_entry_trampoline)
> NOKPROBE(__sdei_asm_entry_trampoline)
> ----------%<----------
>
> Good news - this didn't happen with v5.10.
>
> I don't see this in v5.4.185 yet.
>
> Greg/Sasha, what is least work for you?:
> A new version of this patch,
> A fixup on top of the series,
> Reposting the series with this fixed.
Let me merge this into this commit.
thanks!
greg k-h
On 3/18/2022 5:11 AM, James Morse wrote:
> Hi Florian,
>
> On 3/17/22 8:48 PM, Florian Fainelli wrote:
>> On 3/17/22 5:45 AM, Greg Kroah-Hartman wrote:
>>> From: James Morse <[email protected]>
>>>
>>> commit b28a8eebe81c186fdb1a0078263b30576c8e1f42 upstream.
>>>
>>> The trampoline code needs to use the address of symbols in the wider
>>> kernel, e.g. vectors. PC-relative addressing wouldn't work as the
>>> trampoline code doesn't run at the address the linker expected.
>>>
>>> tramp_ventry uses a literal pool, unless CONFIG_RANDOMIZE_BASE is
>>> set, in which case it uses the data page as a literal pool because
>>> the data page can be unmapped when running in user-space, which is
>>> required for CPUs vulnerable to meltdown.
>>>
>>> Pull this logic out as a macro, instead of adding a third copy
>>> of it.
>>>
>>> Reviewed-by: Catalin Marinas <[email protected]>
>>> Signed-off-by: James Morse <[email protected]>
>>> Signed-off-by: Sasha Levin <[email protected]>
>>
>> This commit causes a linking failure with CONFIG_ARM_SDE_INTERFACE=y
>> enabled in the kernel:
>>
>> LD .tmp_vmlinux.kallsyms1
>> /local/users/fainelli/buildroot/output/arm64/host/bin/aarch64-linux-ld:
>> arch/arm64/kernel/entry.o: in function `__sdei_asm_exit_trampoline':
>> /local/users/fainelli/buildroot/output/arm64/build/linux-custom/arch/arm64/kernel/entry.S:1352:
>>
>> undefined reference to `__sdei_asm_trampoline_next_handler'
>> make[2]: *** [Makefile:1100: vmlinux] Error 1
>> make[1]: *** [package/pkg-generic.mk:295:
>> /local/users/fainelli/buildroot/output/arm64/build/linux-custom/.stamp_built]
>>
>> Error 2
>> make: *** [Makefile:27: _all] Error 2
>
> ... and with CONFIG_RANDOMIZE_BASE turned off, which is why allyesconfig
> didn't catch it.
Yes that is correct CONFIG_RANDOMIZE_BASE is turned off in the
configuration file I used.
> This is because I kept the next_handler bit of the label when it
> conflicted, which isn't needed
> because the __entry_tramp bit added by the macro serves the same purpose.
>
> The below diff fixes it:
> ----------%<----------
> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> index e4b5a15c2e2e..cfc0bb6c49f7 100644
> --- a/arch/arm64/kernel/entry.S
> +++ b/arch/arm64/kernel/entry.S
> @@ -1190,7 +1190,7 @@ __entry_tramp_data_start:
> __entry_tramp_data_vectors:
> .quad vectors
> #ifdef CONFIG_ARM_SDE_INTERFACE
> -__entry_tramp_data___sdei_asm_trampoline_next_handler:
> +__entry_tramp_data___sdei_asm_handler:
> .quad __sdei_asm_handler
> #endif /* CONFIG_ARM_SDE_INTERFACE */
> .popsection // .rodata
> @@ -1319,7 +1319,7 @@ ENTRY(__sdei_asm_entry_trampoline)
> */
> 1: str x4, [x1, #(SDEI_EVENT_INTREGS + S_ORIG_ADDR_LIMIT)]
>
> - tramp_data_read_var x4, __sdei_asm_trampoline_next_handler
> + tramp_data_read_var x4, __sdei_asm_handler
> br x4
> ENDPROC(__sdei_asm_entry_trampoline)
> NOKPROBE(__sdei_asm_entry_trampoline)
> ----------%<----------
>
> Good news - this didn't happen with v5.10.
>
> I don't see this in v5.4.185 yet.
>
> Greg/Sasha, what is least work for you?:
> A new version of this patch,
> A fixup on top of the series,
> Reposting the series with this fixed.
FWIW, applying your patch on top of the entire 5.4.186-rc1 series will
fail with some rejects so that would require you to fixup the patch
instead, and then I suppose the whole -rc1 now becomes an -rc2?
>
>
> Thanks for catching this!
Thanks for the quick turnaround:
Tested-by: Florian Fainelli <[email protected]>
--
Florian
On Fri, Mar 18, 2022 at 05:18:39PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 18, 2022 at 12:11:32PM +0000, James Morse wrote:
> > Hi Florian,
> >
> > On 3/17/22 8:48 PM, Florian Fainelli wrote:
> > > On 3/17/22 5:45 AM, Greg Kroah-Hartman wrote:
> > > > From: James Morse <[email protected]>
> > > >
> > > > commit b28a8eebe81c186fdb1a0078263b30576c8e1f42 upstream.
> > > >
> > > > The trampoline code needs to use the address of symbols in the wider
> > > > kernel, e.g. vectors. PC-relative addressing wouldn't work as the
> > > > trampoline code doesn't run at the address the linker expected.
> > > >
> > > > tramp_ventry uses a literal pool, unless CONFIG_RANDOMIZE_BASE is
> > > > set, in which case it uses the data page as a literal pool because
> > > > the data page can be unmapped when running in user-space, which is
> > > > required for CPUs vulnerable to meltdown.
> > > >
> > > > Pull this logic out as a macro, instead of adding a third copy
> > > > of it.
> > > >
> > > > Reviewed-by: Catalin Marinas <[email protected]>
> > > > Signed-off-by: James Morse <[email protected]>
> > > > Signed-off-by: Sasha Levin <[email protected]>
> > >
> > > This commit causes a linking failure with CONFIG_ARM_SDE_INTERFACE=y
> > > enabled in the kernel:
> > >
> > > LD .tmp_vmlinux.kallsyms1
> > > /local/users/fainelli/buildroot/output/arm64/host/bin/aarch64-linux-ld:
> > > arch/arm64/kernel/entry.o: in function `__sdei_asm_exit_trampoline':
> > > /local/users/fainelli/buildroot/output/arm64/build/linux-custom/arch/arm64/kernel/entry.S:1352:
> > > undefined reference to `__sdei_asm_trampoline_next_handler'
> > > make[2]: *** [Makefile:1100: vmlinux] Error 1
> > > make[1]: *** [package/pkg-generic.mk:295:
> > > /local/users/fainelli/buildroot/output/arm64/build/linux-custom/.stamp_built]
> > > Error 2
> > > make: *** [Makefile:27: _all] Error 2
> >
> > ... and with CONFIG_RANDOMIZE_BASE turned off, which is why allyesconfig didn't catch it.
> > This is because I kept the next_handler bit of the label when it conflicted, which isn't needed
> > because the __entry_tramp bit added by the macro serves the same purpose.
> >
> > The below diff fixes it:
> > ----------%<----------
> > diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
> > index e4b5a15c2e2e..cfc0bb6c49f7 100644
> > --- a/arch/arm64/kernel/entry.S
> > +++ b/arch/arm64/kernel/entry.S
> > @@ -1190,7 +1190,7 @@ __entry_tramp_data_start:
> > __entry_tramp_data_vectors:
> > .quad vectors
> > #ifdef CONFIG_ARM_SDE_INTERFACE
> > -__entry_tramp_data___sdei_asm_trampoline_next_handler:
> > +__entry_tramp_data___sdei_asm_handler:
> > .quad __sdei_asm_handler
> > #endif /* CONFIG_ARM_SDE_INTERFACE */
> > .popsection // .rodata
> > @@ -1319,7 +1319,7 @@ ENTRY(__sdei_asm_entry_trampoline)
> > */
> > 1: str x4, [x1, #(SDEI_EVENT_INTREGS + S_ORIG_ADDR_LIMIT)]
> > - tramp_data_read_var x4, __sdei_asm_trampoline_next_handler
> > + tramp_data_read_var x4, __sdei_asm_handler
> > br x4
> > ENDPROC(__sdei_asm_entry_trampoline)
> > NOKPROBE(__sdei_asm_entry_trampoline)
> > ----------%<----------
> >
> > Good news - this didn't happen with v5.10.
> >
> > I don't see this in v5.4.185 yet.
> >
> > Greg/Sasha, what is least work for you?:
> > A new version of this patch,
> > A fixup on top of the series,
> > Reposting the series with this fixed.
>
> Let me merge this into this commit.
Well I would if it would actually apply :(
Can you send a version that isn't whitespace corrupted?
thanks,
greg k-h