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.
