[PATCH v2 09/13] powerpc/ftrace: Implement CONFIG_DYNAMIC_FTRACE_WITH_ARGS
Michael Ellerman
mpe at ellerman.id.au
Tue Feb 15 22:05:04 AEDT 2022
Christophe Leroy <christophe.leroy at csgroup.eu> writes:
> Le 14/02/2022 à 16:25, Naveen N. Rao a écrit :
>> Christophe Leroy wrote:
>>> Implement CONFIG_DYNAMIC_FTRACE_WITH_ARGS. It accelerates the call
>>> of livepatching.
>>>
>>> Also note that powerpc being the last one to convert to
>>> CONFIG_DYNAMIC_FTRACE_WITH_ARGS, it will now be possible to remove
>>> klp_arch_set_pc() on all architectures.
>>>
>>> Signed-off-by: Christophe Leroy <christophe.leroy at csgroup.eu>
>>> ---
>>> arch/powerpc/Kconfig | 1 +
>>> arch/powerpc/include/asm/ftrace.h | 17 +++++++++++++++++
>>> arch/powerpc/include/asm/livepatch.h | 4 +---
>>> 3 files changed, 19 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>>> index cdac2115eb00..e2b1792b2aae 100644
>>> --- a/arch/powerpc/Kconfig
>>> +++ b/arch/powerpc/Kconfig
>>> @@ -210,6 +210,7 @@ config PPC
>>> select HAVE_DEBUG_KMEMLEAK
>>> select HAVE_DEBUG_STACKOVERFLOW
>>> select HAVE_DYNAMIC_FTRACE
>>> + select HAVE_DYNAMIC_FTRACE_WITH_ARGS if MPROFILE_KERNEL || PPC32
>>> select HAVE_DYNAMIC_FTRACE_WITH_REGS if MPROFILE_KERNEL || PPC32
>>> select HAVE_EBPF_JIT
>>> select HAVE_EFFICIENT_UNALIGNED_ACCESS if !(CPU_LITTLE_ENDIAN
>>> && POWER7_CPU)
>>> diff --git a/arch/powerpc/include/asm/ftrace.h
>>> b/arch/powerpc/include/asm/ftrace.h
>>> index b3f6184f77ea..45c3d6f11daa 100644
>>> --- a/arch/powerpc/include/asm/ftrace.h
>>> +++ b/arch/powerpc/include/asm/ftrace.h
>>> @@ -22,6 +22,23 @@ static inline unsigned long
>>> ftrace_call_adjust(unsigned long addr)
>>> struct dyn_arch_ftrace {
>>> struct module *mod;
>>> };
>>> +
>>> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_ARGS
>>> +struct ftrace_regs {
>>> + struct pt_regs regs;
>>> +};
>>> +
>>> +static __always_inline struct pt_regs *arch_ftrace_get_regs(struct
>>> ftrace_regs *fregs)
>>> +{
>>> + return &fregs->regs;
>>> +}
>>
>> I think this is wrong. We need to differentiate between ftrace_caller()
>> and ftrace_regs_caller() here, and only return pt_regs if coming in
>> through ftrace_regs_caller() (i.e., FL_SAVE_REGS is set).
>
> Not sure I follow you.
>
> This is based on 5740a7c71ab6 ("s390/ftrace: add
> HAVE_DYNAMIC_FTRACE_WITH_ARGS support")
>
> It's all the point of HAVE_DYNAMIC_FTRACE_WITH_ARGS, have the regs also
> with ftrace_caller().
>
> Sure you only have the params, but that's the same on s390, so what did
> I miss ?
I already have this series in next, I can pull it out, but I'd rather
not.
I'll leave it in for now, hopefully you two can agree overnight my time
whether this is a big problem or something we can fix with a fixup
patch.
>>> +static __always_inline void ftrace_instruction_pointer_set(struct
>>> ftrace_regs *fregs,
>>> + unsigned long ip)
>>> +{
>>> + regs_set_return_ip(&fregs->regs, ip);
>>
>> Should we use that helper here? regs_set_return_ip() also updates some
>> other state related to taking interrupts and I don't think it makes
>> sense for use with ftrace.
>
>
> Today we have:
>
> static inline void klp_arch_set_pc(struct ftrace_regs *fregs, unsigned
> long ip)
> {
> struct pt_regs *regs = ftrace_get_regs(fregs);
>
> regs_set_return_ip(regs, ip);
> }
>
>
> Which like x86 and s390 becomes:
>
> static inline void klp_arch_set_pc(struct ftrace_regs *fregs, unsigned
> long ip)
> {
> ftrace_instruction_pointer_set(fregs, ip);
> }
>
>
>
> That's the reason why I've been using regs_set_return_ip(). Do you think
> it was wrong to use regs_set_return_ip() in klp_arch_set_pc() ?
>
> That was added by 59dc5bfca0cb ("powerpc/64s: avoid reloading (H)SRR
> registers if they are still valid")
It's not wrong, but I think it's unnecessary. We need to use
regs_set_return_ip() if we're changing the regs->ip of an interrupt
frame, so that the interrupt return code will reload it.
But AIUI in this case we're not doing that, we're changing the regs->ip
of a pt_regs provided by ftrace, which shouldn't ever be an interrupt
frame.
So it's not a bug to use regs_set_return_ip(), but it is unncessary and
means we'll reload the interrupt state unnecessarily on the next
interrupt return.
cheers
More information about the Linuxppc-dev
mailing list