Re: [PATCH v2 bpf-next] Add support for tracing programs in BPF_PROG_RUN

[Martin KaFai Lau <martin.lau@linux.dev>]

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@linux.dev> 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@linux.dev> 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.