On Sat, Apr 26, 2025 at 9:00 AM KaFai Wan <[email protected]> wrote: > > Adding support to use get_func_[arg|arg_cnt] helpers in raw_tp/tp_btf > programs. > > We can use get_func_[arg|ret|arg_cnt] helpers in fentry/fexit/fmod_ret > programs currently. If we try to use get_func_[arg|arg_cnt] helpers in > raw_tp/tp_btf programs, verifier will fail to load the program with: > > ; __u64 cnt = bpf_get_func_arg_cnt(ctx); > 3: (85) call bpf_get_func_arg_cnt#185 > unknown func bpf_get_func_arg_cnt#185 > > Adding get_func_[arg|arg_cnt] helpers in raw_tp_prog_func_proto and > tracing_prog_func_proto for raw tracepoint. > > Adding 1 arg on ctx of raw tracepoint program and make it stores number of > arguments on ctx-8, so it's easy to verify argument index and find > argument's position. > > Signed-off-by: KaFai Wan <[email protected]> > --- > kernel/trace/bpf_trace.c | 17 ++++++++++++++--- > net/bpf/test_run.c | 13 +++++-------- > 2 files changed, 19 insertions(+), 11 deletions(-) > > diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c > index 52c432a44aeb..eb4c56013493 100644 > --- a/kernel/trace/bpf_trace.c > +++ b/kernel/trace/bpf_trace.c > @@ -1892,6 +1892,10 @@ raw_tp_prog_func_proto(enum bpf_func_id func_id, const > struct bpf_prog *prog) > return &bpf_get_stackid_proto_raw_tp; > case BPF_FUNC_get_stack: > return &bpf_get_stack_proto_raw_tp; > + case BPF_FUNC_get_func_arg: > + return &bpf_get_func_arg_proto; > + case BPF_FUNC_get_func_arg_cnt: > + return &bpf_get_func_arg_cnt_proto; > case BPF_FUNC_get_attach_cookie: > return &bpf_get_attach_cookie_proto_tracing; > default: > @@ -1950,10 +1954,16 @@ tracing_prog_func_proto(enum bpf_func_id func_id, > const struct bpf_prog *prog) > case BPF_FUNC_d_path: > return &bpf_d_path_proto; > case BPF_FUNC_get_func_arg: > + if (prog->type == BPF_PROG_TYPE_TRACING && > + prog->expected_attach_type == BPF_TRACE_RAW_TP) > + return &bpf_get_func_arg_proto; > return bpf_prog_has_trampoline(prog) ? > &bpf_get_func_arg_proto : NULL; > case BPF_FUNC_get_func_ret: > return bpf_prog_has_trampoline(prog) ? > &bpf_get_func_ret_proto : NULL; > case BPF_FUNC_get_func_arg_cnt: > + if (prog->type == BPF_PROG_TYPE_TRACING && > + prog->expected_attach_type == BPF_TRACE_RAW_TP) > + return &bpf_get_func_arg_cnt_proto; > return bpf_prog_has_trampoline(prog) ? > &bpf_get_func_arg_cnt_proto : NULL; > case BPF_FUNC_get_attach_cookie: > if (prog->type == BPF_PROG_TYPE_TRACING && > @@ -2312,7 +2322,7 @@ void __bpf_trace_run(struct bpf_raw_tp_link *link, u64 > *args) > #define REPEAT(X, FN, DL, ...) REPEAT_##X(FN, DL, __VA_ARGS__) > > #define SARG(X) u64 arg##X > -#define COPY(X) args[X] = arg##X > +#define COPY(X) args[X + 1] = arg##X > > #define __DL_COM (,) > #define __DL_SEM (;) > @@ -2323,9 +2333,10 @@ void __bpf_trace_run(struct bpf_raw_tp_link *link, u64 > *args) > void bpf_trace_run##x(struct bpf_raw_tp_link *link, \ > REPEAT(x, SARG, __DL_COM, __SEQ_0_11)) \ > { \ > - u64 args[x]; \ > + u64 args[x + 1]; \ > + args[0] = x; \ > REPEAT(x, COPY, __DL_SEM, __SEQ_0_11); \ > - __bpf_trace_run(link, args); \ > + __bpf_trace_run(link, args + 1); \
This is neat, but what is this for? The program that attaches to a particular raw_tp knows what it is attaching to and how many arguments are there, so bpf_get_func_arg_cnt() is a 5th wheel. If the reason is "for completeness" then it's not a good reason to penalize performance. Though it's just an extra 8 byte of stack and a single store of a constant. pw-bot: cr
