On Wed, Jul 07, 2021 at 07:11:23PM -0700, Alexei Starovoitov wrote: > On Wed, Jul 07, 2021 at 11:47:47PM +0200, Jiri Olsa wrote: > > > > +static bool allow_get_func_ip_tracing(struct bpf_verifier_env *env) > > +{ > > + return env->prog->jit_requested && IS_ENABLED(CONFIG_X86_64); > > Why does it have to be gated by 'jited && x86_64' ? > It's gated by bpf trampoline and it's only implemented on x86_64 so far. > The trampoline has plenty of features. I would expect bpf trampoline > for arm64 to implement all of them. If not the func_ip would be just > one of the trampoline features that couldn't be implemented and at that > time we'd need a flag mask of a sort, but I'd rather push of feature > equivalence between trampoline implementations. ok, check for trampoline's prog types should be enough > > Then jited part also doesn't seem to be necessary. > The trampoline passed pointer to a stack in R1. > Interpreter should deal with BPF_LDX_MEM(BPF_DW, BPF_REG_0, BPF_REG_1, -8) insn > the same way and it should work, since trampoline prepared it. > What did I miss? ah right.. will remove that SNIP > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > > index 64bd2d84367f..9edd3b1a00ad 100644 > > --- a/kernel/trace/bpf_trace.c > > +++ b/kernel/trace/bpf_trace.c > > @@ -948,6 +948,19 @@ const struct bpf_func_proto bpf_snprintf_btf_proto = { > > .arg5_type = ARG_ANYTHING, > > }; > > > > +BPF_CALL_1(bpf_get_func_ip_tracing, void *, ctx) > > +{ > > + /* Stub, the helper call is inlined in the program. */ > > + return 0; > > +} > > may be add a WARN in here that it should never be executed ? > Or may be add an actual implementation: > return ((u64 *)ctx)[-1]; > and check that it works without inlining by the verifier? > sure, but having tracing program with this helper, it will be always inlined, right? I can't see how it could be skipped thanks, jirka