Re: [PATCH 2/4] powerpc/kuap: Avoid useless jump_label on empty function
From: Nicholas Piggin
Date: Tue Jun 06 2023 - 05:12:24 EST
On Mon Jun 5, 2023 at 9:04 PM AEST, Christophe Leroy wrote:
> Disassembly of interrupt_enter_prepare() shows a pointless nop before the mftb
>
> c000abf0 <interrupt_enter_prepare>:
> c000abf0: 81 23 00 84 lwz r9,132(r3)
> c000abf4: 71 29 40 00 andi. r9,r9,16384
> c000abf8: 41 82 00 28 beq- c000ac20 <interrupt_enter_prepare+0x30>
> c000abfc: ===> 60 00 00 00 nop <====
> c000ac00: 7d 0c 42 e6 mftb r8
> c000ac04: 80 e2 00 08 lwz r7,8(r2)
> c000ac08: 81 22 00 28 lwz r9,40(r2)
> c000ac0c: 91 02 00 24 stw r8,36(r2)
> c000ac10: 7d 29 38 50 subf r9,r9,r7
> c000ac14: 7d 29 42 14 add r9,r9,r8
> c000ac18: 91 22 00 08 stw r9,8(r2)
> c000ac1c: 4e 80 00 20 blr
> c000ac20: 60 00 00 00 nop
> c000ac24: 7d 5a c2 a6 mfmd_ap r10
> c000ac28: 3d 20 de 00 lis r9,-8704
> c000ac2c: 91 43 00 b0 stw r10,176(r3)
> c000ac30: 7d 3a c3 a6 mtspr 794,r9
> c000ac34: 4e 80 00 20 blr
>
> That comes from the call to kuap_loc(), allthough __kuap_lock() is an empty
> function on the 8xx.
>
> To avoid that, only perform kuap_is_disabled() check when there is something
> to do with __kuap_lock().
>
> Do the same with __kuap_save_and_lock() and __kuap_get_and_assert_locked().
Too bad static branch nops can't be eliminated.
> diff --git a/arch/powerpc/include/asm/book3s/64/kup.h b/arch/powerpc/include/asm/book3s/64/kup.h
> index 54cf46808157..1b0215ff3710 100644
> --- a/arch/powerpc/include/asm/book3s/64/kup.h
> +++ b/arch/powerpc/include/asm/book3s/64/kup.h
> @@ -297,15 +297,7 @@ static inline unsigned long __kuap_get_and_assert_locked(void)
> WARN_ON_ONCE(amr != AMR_KUAP_BLOCKED);
> return amr;
> }
> -
> -/* Do nothing, book3s/64 does that in ASM */
> -static inline void __kuap_lock(void)
> -{
> -}
> -
> -static inline void __kuap_save_and_lock(struct pt_regs *regs)
> -{
> -}
> +#define __kuap_get_and_assert_locked __kuap_get_and_assert_locked
Maybe leave in /* __kuap_lock notrequired, book3s/64 does that in ASM */
? Seems okay though
Reviewed-by: Nicholas Piggin <npiggin@xxxxxxxxx>
Thanks,
Nick