On Wed, Aug 5, 2020 at 10:45 AM Alexei Starovoitov <alexei.starovoi...@gmail.com> wrote: > > On Wed, Aug 05, 2020 at 10:27:28AM -0700, Andrii Nakryiko wrote: > > On Wed, Aug 5, 2020 at 10:16 AM Alexei Starovoitov > > <alexei.starovoi...@gmail.com> wrote: > > > > > > On Wed, Aug 05, 2020 at 04:47:30AM +0000, Song Liu wrote: > > > > > > > > Being able to trigger BPF program on a different CPU could enable many > > > > use cases and optimizations. The use case I am looking at is to access > > > > perf_event and percpu maps on the target CPU. For example: > > > > 0. trigger the program > > > > 1. read perf_event on cpu x; > > > > 2. (optional) check which process is running on cpu x; > > > > 3. add perf_event value to percpu map(s) on cpu x. > > > > > > If the whole thing is about doing the above then I don't understand why > > > new > > > prog type is needed. Can prog_test_run support existing > > > BPF_PROG_TYPE_KPROBE? > > > "enable many use cases" sounds vague. I don't think folks reading > > > the patches can guess those "use cases". > > > "Testing existing kprobe bpf progs" would sound more convincing to me. > > > > Was just about to propose the same :) I wonder if generic test_run() > > capability to trigger test programs of whatever supported type on a > > specified CPU through IPI can be added. That way you can even use the > > XDP program to do what Song seems to need. > > > > TRACEPOINTs might also be a good fit here, given it seems simpler to > > let users specify custom tracepoint data for test_run(). Having the > > ability to unit-test KPROBE and TRACEPOINT, however rudimentary, is > > already a big win. > > > > > If the test_run framework can be extended to trigger kprobe with correct > > > pt_regs. > > > As part of it test_run would trigger on a given cpu with $ip pointing > > > to some test fuction in test_run.c. For local test_run the stack trace > > > would include bpf syscall chain. For IPI the stack trace would include > > > the corresponding kernel pieces where top is our special test function. > > > Sort of like pseudo kprobe where there is no actual kprobe logic, > > > since kprobe prog doesn't care about mechanism. It needs correct > > > pt_regs only as input context. > > > The kprobe prog output (return value) has special meaning though, > > > so may be kprobe prog type is not a good fit. > > > > It does? I don't remember returning 1 from KPROBE changing anything. I > > thought it's only the special bpf_override_return() that can influence > > the kernel function return result. > > See comment in trace_call_bpf(). > And logic to handle it in kprobe_perf_func() for kprobes. > and in perf_trace_run_bpf_submit() for tracepoints. > It's historical and Song actually discovered an issue with such behavior. > I don't remember whether we've concluded on the solution.
Oh, thanks for pointers. Never realized there is more going on with those. I guess return 1; is not advised then, as it causes extra overhead.
