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
