On Tue, Feb 7, 2023 at 8:05 PM Martin KaFai Lau <martin.lau@xxxxxxxxx> wrote:
>
> On 2/7/23 7:46 AM, Grant Seltzer Richman wrote:
> > On Mon, Feb 6, 2023 at 3:37 PM Martin KaFai Lau <martin.lau@xxxxxxxxx> wrote:
> >>
> >> On 2/5/23 9:29 AM, Grant Seltzer Richman wrote:
> >>> On Sat, Feb 4, 2023 at 1:58 AM Martin KaFai Lau <martin.lau@xxxxxxxxx> wrote:
> >>>>
> >>>> On 2/3/23 10:28 AM, Grant Seltzer wrote:
> >>>>> This patch changes the behavior of how BPF_PROG_RUN treats tracing
> >>>>> (fentry/fexit) programs. Previously only a return value is injected
> >>>>> but the actual program was not run.
> >>>>
> >>>> hmm... I don't understand this. The actual program is run by attaching to the
> >>>> bpf_fentry_test{1,2,3...}. eg. The test in fentry_test.c
> >>>
> >>> I'm not sure what you mean. Are you saying in order to use the
> >>> BPF_PROG_RUN bpf syscall command the user must first attach to
> >>> `bpf_fentry_test1` (or any 1-8), and then execute the BPF_PROG_RUN?
> >>
> >> It is how the fentry/fexit/fmod_ret...BPF_PROG_TYPE_TRACIN_xxx prog is setup to
> >> run now in test_run. afaik, these tracing progs require the trampoline setup
> >> before calling the bpf prog, so don't understand how __bpf_prog_test_run_tracing
> >> will work safely.
> >
> > My goal is to be able to take a bpf program of type
> > BPF_PROG_TYPE_TRACING and run it via BPF_PROG_TEST_RUN without having
> > to attach it. The motivation is testing. You can run tracing programs
> > but the actual program isn't run, from the users perspective the
> > syscall just returns 0. You can see how I'm testing this here [1].
> >
> > If I understand you correctly, it's possible to do something like
> > this, can you give me more information on how I can and I'll be sure
> > to submit documentation for it?
> >
> > [1] https://github.com/grantseltzer/bpf-prog-test-run/tree/main/programs
>
> In raw tracepoint, the "ctx" is just a u64 array for the args.
>
> fentry/fexit/fmod_ret is much demanding than preparing a u64 array. The
> trampoline is preparing more than just 'args'. The trampoline is likely to be
> expanded and changed in the future also. You can take a look at
> arch_prepare_bpf_trampoline().
>
> Yes, might be the trampoline preparation can be reused. However, I am not
> convinced tracing program can be tested through test_run in a meaningful and
> reliable way to worth this complication. eg. A tracing function taking 'struct
> task_struct *task'. It is not easy for the user space program to prepare the ctx
> containing a task_struct and the task_struct layout may change also. There are
> so many traceable kernel functions and I don't think test_run can ever become a
> single point to test tracing prog for all kernel functions.
> [ Side-note: test_run for skb/xdp has much narrower focus in terms of argument
> because it is driven by the packet header like the standard IPv6/TCP/UDP. ]
>
> Even for bpf_prog_test_run_raw_tp, the raw_tp_test_run.c is mostly testing if
> the prog is running on a particular cpu. It is not looking into the args which
> is what the tracing prog usually does.
>
> Please attach the tracing prog to the kernel function to test
> or reuse the existing bpf_prog_test_run_raw_tp to test it if it does not care
> the args.
Thank you for the explanation, I understand!
