On Tue, 25 Jan 2022 19:11:52 +0100 Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > On Tue, Jan 25, 2022 at 05:41:24PM +0100, Jiri Olsa wrote: > > On Tue, Jan 25, 2022 at 09:11:57PM +0900, Masami Hiramatsu wrote: > > > > SNIP > > > > > + > > > +/* Convert ftrace location address from symbols */ > > > +static int convert_func_addresses(struct fprobe *fp) > > > +{ > > > + unsigned long addr, size; > > > + unsigned int i; > > > + > > > + /* Convert symbols to symbol address */ > > > + if (fp->syms) { > > > + fp->addrs = kcalloc(fp->nentry, sizeof(*fp->addrs), GFP_KERNEL); > > > + if (!fp->addrs) > > > + return -ENOMEM; > > > + > > > + for (i = 0; i < fp->nentry; i++) { > > > + fp->addrs[i] = kallsyms_lookup_name(fp->syms[i]); > > > + if (!fp->addrs[i]) /* Maybe wrong symbol */ > > > + goto error; > > > + } > > > + } > > > + > > > + /* Convert symbol address to ftrace location. */ > > > + for (i = 0; i < fp->nentry; i++) { > > > + if (!kallsyms_lookup_size_offset(fp->addrs[i], &size, NULL)) > > > + size = MCOUNT_INSN_SIZE; > > > + addr = ftrace_location_range(fp->addrs[i], fp->addrs[i] + size); > > > > you need to substract 1 from 'end' in here, as explained in > > __within_notrace_func comment: > > > > /* > > * Since ftrace_location_range() does inclusive range check, we need > > * to subtract 1 byte from the end address. > > */ > > > > like in the patch below Good catch, I missed that point. > > also this convert is for archs where address from kallsyms does not match > > the real attach addresss, like for arm you mentioned earlier, right? Yes, that's right. > > > > could we have that arch specific, so we don't have extra heavy search > > loop for archs that do not need it? Hmm, is that so heavy? Even though, this kind of convertion is better to be implemented in the arch-specific ftrace. They may know the best way to do, because the offset is fixed for each arch. > > one more question.. > > I'm adding support for user to pass function symbols to bpf fprobe link > and I thought I'd pass symbols array to register_fprobe, but I'd need to > copy the whole array of strings from user space first, which could take > lot of memory considering attachment of 10k+ functions > > so I'm thinking better way is to resolve symbols already in bpf fprobe > link code and pass just addresses to register_fprobe That is OK. Fprobe accepts either ::syms or ::addrs. > > I assume you want to keep symbol interface, right? could we have some > flag ensuring the conversion code is skipped, so we don't go through > it twice? Yeah, we still have many unused bits in fprobe::flags. :) Thank you, > in any case I need addresses before I call register_fprobe, because > of the bpf cookies setup > > thanks, > jirka > -- Masami Hiramatsu <mhiramat@xxxxxxxxxx>