[PATCH] powerpc: Inline setup_kup()

Michael Ellerman mpe at ellerman.id.au
Tue Dec 15 21:20:53 AEDT 2020


Christophe Leroy <christophe.leroy at csgroup.eu> writes:
> Le 15/12/2020 à 02:42, Michael Ellerman a écrit :
>> Christophe Leroy <christophe.leroy at csgroup.eu> writes:
>>> Le 14/12/2020 à 13:30, Michael Ellerman a écrit :
>>>> setup_kup() is used by both 64-bit and 32-bit code. However on 64-bit
>>>> it must not be __init, because it's used for CPU hotplug, whereas on
>>>> 32-bit it should be __init because it calls setup_kuap/kuep() which
>>>> are __init.
>>>>
>>>> We worked around that problem in the past by marking it __ref, see
>>>> commit 67d53f30e23e ("powerpc/mm: fix section mismatch for
>>>> setup_kup()").
>>>>
>>>> Marking it __ref basically just omits it from section mismatch
>>>> checking, which can lead to bugs, and in fact it did, see commit
>>>> 44b4c4450f8d ("powerpc/64s: Mark the kuap/kuep functions non __init")
>>>>
>>>> We can avoid all these problems by just making it static inline.
>>>> Because all it does is call other functions, making it inline actually
>>>> shrinks the 32-bit vmlinux by ~76 bytes.
>>>>
>>>> Signed-off-by: Michael Ellerman <mpe at ellerman.id.au>
>>>> ---
>>>>    arch/powerpc/include/asm/kup.h | 8 ++++++--
>>>>    arch/powerpc/mm/init-common.c  | 6 ------
>>>>    2 files changed, 6 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/arch/powerpc/include/asm/kup.h b/arch/powerpc/include/asm/kup.h
>>>> index 5a9820c54da9..46b12c6dc728 100644
>>>> --- a/arch/powerpc/include/asm/kup.h
>>>> +++ b/arch/powerpc/include/asm/kup.h
>>>> @@ -49,8 +49,6 @@ extern bool disable_kuap;
>>>>    
>>>>    #include <linux/pgtable.h>
>>>>    
>>>> -void setup_kup(void);
>>>> -
>>>>    #ifdef CONFIG_PPC_KUEP
>>>>    void setup_kuep(bool disabled);
>>>>    #else
>>>> @@ -85,6 +83,12 @@ static inline void restore_user_access(unsigned long flags) { }
>>>>    #endif /* CONFIG_PPC_BOOK3S_64 */
>>>>    #endif /* CONFIG_PPC_KUAP */
>>>>    
>>>> +static inline void setup_kup(void)
>>>
>>> Should it be __always_inline ?
>> 
>> Yes I guess so, will fix. Thanks for reviewing.
>> 
>
> While we are talking about __always_inline, do you plan to take the following patch this cycle ?
>
> https://patchwork.ozlabs.org/project/linuxppc-dev/patch/a1d31f84ddb0926813b17fcd5cc7f3fa7b4deac2.1602759123.git.christophe.leroy@csgroup.eu/

I intended to, will grab it now.

cheers


More information about the Linuxppc-dev mailing list