On Fri, Jan 24, 2025 at 12:23:35PM +0100, Jiri Olsa wrote: > On Thu, Jan 23, 2025 at 02:32:38PM -0800, Martin KaFai Lau wrote: > > Hi Jiri, > > > > The "missed/kprobe_recursion" fails consistently on s390. It seems to start > > failing after the recent bpf and bpf-next tree ffwd. > > > > An example: > > https://github.com/kernel-patches/bpf/actions/runs/12934431612/job/36076956920 > > > > Can you help to take a look? > > > > afaict, it only happens on s390 so far, so cc IIya if there is any recent > > change that may ring the bell. > > hi, > I need to check more but I wonder it's the: > 7495e179b478 s390/tracing: Enable HAVE_FTRACE_GRAPH_FUNC > > which seems to add recursion check and bail out before we have > a chance to trigger it in bpf code so the test attaches bpf program test1 to bpf_fentry_test1 via kprobe.multi SEC("kprobe.multi/bpf_fentry_test1") int test1(struct pt_regs *ctx) { bpf_kfunc_common_test(); return 0; } and several other programs are attached to bpf_kfunc_common_test function I can't test this on s390, but looks like following is happening: kprobe.multi uses fprobe, so the test kernel path goes: bpf_fentry_test1 ftrace_graph_func function_graph_enter_regs fprobe_entry kprobe_multi_link_prog_run test1 (bpf program) bpf_kfunc_common_test kprobe_ftrace_handler kprobe_perf_func trace_call_bpf -> bpf_prog_active check fails, missed count is incremented kprobe_ftrace_handler calls/takes ftrace_test_recursion_trylock (ftrace recursion lock) but s390 now calls/takes ftrace_test_recursion_trylock already in ftrace_graph_func, so s390 stops at kprobe_ftrace_handler and does not get to trace_call_bpf to increment prog->missed counters adding Sven, Masami, any idea? if the ftrace_test_recursion_trylock is needed ftrace_graph_func on s390, then I think we will need to fix our test to skip s390 arch thanks, jirka