Re: [PATCHv2 bpf-next 2/6] ftrace: Keep the resolved addr in kallsyms_callback

[Jiri Olsa <olsajiri@gmail.com>]

On Mon, Aug 15, 2022 at 02:45:54PM +0200, Peter Zijlstra wrote:
> On Mon, Aug 15, 2022 at 12:30:46PM +0200, Jiri Olsa wrote:
> > On Mon, Aug 15, 2022 at 12:13:39PM +0200, Peter Zijlstra wrote:
> > > On Thu, Aug 11, 2022 at 11:15:22AM +0200, Jiri Olsa wrote:
> > > > Keeping the resolved 'addr' in kallsyms_callback, instead of taking
> > > > ftrace_location value, because we depend on symbol address in the
> > > > cookie related code.
> > > > 
> > > > With CONFIG_X86_KERNEL_IBT option the ftrace_location value differs
> > > > from symbol address, which screwes the symbol address cookies matching.
> > > > 
> > > > There are 2 users of this function:
> > > > - bpf_kprobe_multi_link_attach
> > > >     for which this fix is for
> > > 
> > > Except you fail to explain what the problem is and how this helps
> > > anything.
> > 
> > we search this array of resolved addresses later in cookie code
> > (bpf_kprobe_multi_cookie) for address returned by fprobe, which
> > is not 'ftrace_location' address
> 
> What is fprobe?

https://lore.kernel.org/bpf/164800288611.1716332.7053663723617614668.stgit@devnote2/

> 
> > so we want ftrace_lookup_symbols to return 'only' resolved address
> > at this point, not 'ftrace_location' address
> 
> In general; I'm completely confused what any of this code is doing.
> Mostly I don't speak BPF *at*all*. And have very little clue as to what
> things are supposed to do, please help me along.
> 
> But the thing is, we're likely going to change all this (function call
> abi) again in the very near future; it would be very nice if all this
> code could grow some what/why comments, because I've gotten lost
> multiple times in all this.

is there any outline of the change? is this the change in your x86/fineibt
branch that you brought up in the other thread? 

jirka