From: Jiri Olsa <olsajiri@gmail.com>
To: Jiri Olsa <olsajiri@gmail.com>,
Sven Schnelle <svens@linux.ibm.com>,
Masami Hiramatsu <mhiramat@kernel.org>
Cc: Martin KaFai Lau <martin.lau@linux.dev>,
Ilya Leoshkevich <iii@linux.ibm.com>, bpf <bpf@vger.kernel.org>
Subject: Re: [TEST FAILURE] bpf: s390: missed/kprobe_recursion
Date: Fri, 24 Jan 2025 16:41:38 +0100 [thread overview]
Message-ID: <Z5O0shrdgeExZ2kF@krava> (raw)
In-Reply-To: <Z5N4N6MUMt8_EwGS@krava>
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
next prev parent reply other threads:[~2025-01-24 15:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-23 22:32 [TEST FAILURE] bpf: s390: missed/kprobe_recursion Martin KaFai Lau
2025-01-24 11:23 ` Jiri Olsa
2025-01-24 15:41 ` Jiri Olsa [this message]
2025-01-26 14:40 ` Masami Hiramatsu
2025-01-26 22:06 ` Jiri Olsa
2025-01-27 19:09 ` Andrii Nakryiko
2025-01-28 4:57 ` Masami Hiramatsu
-- strict thread matches above, loose matches on Subject: below --
2025-01-23 22:32 Martin KaFai Lau
2025-01-23 22:44 ` Martin KaFai Lau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z5O0shrdgeExZ2kF@krava \
--to=olsajiri@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=iii@linux.ibm.com \
--cc=martin.lau@linux.dev \
--cc=mhiramat@kernel.org \
--cc=svens@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.