[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5925436.DvuYhMxLoT@7940hx>
Date: Fri, 19 Sep 2025 16:58:57 +0800
From: Menglong Dong <menglong8.dong@...il.com>
To: Masami Hiramatsu <mhiramat@...nel.org>
Cc: peterz@...radead.org, jolsa@...nel.org, tglx@...utronix.de,
mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org,
hpa@...or.com, kees@...nel.org, samitolvanen@...gle.com, rppt@...nel.org,
luto@...nel.org, mhiramat@...nel.org, ast@...nel.org, andrii@...nel.org,
linux-kernel@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH] x86/ibt: make is_endbr() notrace
On 2025/9/19 16:52 Masami Hiramatsu <mhiramat@...nel.org> write:
> On Thu, 18 Sep 2025 20:09:39 +0800
> Menglong Dong <menglong8.dong@...il.com> wrote:
>
> > is_endbr() is called in __ftrace_return_to_handler -> fprobe_return ->
> > kprobe_multi_link_exit_handler -> is_endbr.
> >
> > It is not protected by the "bpf_prog_active", so it can't be traced by
> > kprobe-multi, which can cause recurring and panic the kernel. Fix it by
> > make it notrace.
>
> Ah, OK. This is fprobe's issue. fprobe depends on fgraph to check
> recursion, but fgraph only detects the recursion in the entry handler.
> Thus it happens in the exit handler, fprobe does not check the recursion.
>
> But since the fprobe provides users to register callback at exit, it
> should check the recursion in return path too.
That's a good idea to provide recursion checking for the exit handler,
which is able to solve this problem too.
If so, we don't need to check the recursion on the kprobe-multi anymore.
Do we?
Thanks!
Menglong Dong
>
> Thanks,
>
> --
> Masami Hiramatsu (Google) <mhiramat@...nel.org>
>
Powered by blists - more mailing lists