Messages in this thread | | | Date | Thu, 6 Jul 2023 12:09:16 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH v2] fprobe: add unlock to match a succeeded ftrace_test_recursion_trylock |
| |
On Mon, 3 Jul 2023 17:23:36 +0800 Ze Gao <zegao2021@gmail.com> wrote:
> Unlock ftrace recursion lock when fprobe_kprobe_handler() is failed > because of some running kprobe. > > Fixes: 3cc4e2c5fbae ("fprobe: make fprobe_kprobe_handler recursion free") > Reported-by: Yafang <laoar.shao@gmail.com> > Closes: https://lore.kernel.org/linux-trace-kernel/CALOAHbC6UpfFOOibdDiC7xFc5YFUgZnk3MZ=3Ny6we=AcrNbew@mail.gmail.com/ > Signed-off-by: Ze Gao <zegao@tencent.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> --- > kernel/trace/fprobe.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c > index 18d36842faf5..93b3e361bb97 100644 > --- a/kernel/trace/fprobe.c > +++ b/kernel/trace/fprobe.c > @@ -102,12 +102,14 @@ static void fprobe_kprobe_handler(unsigned long ip, unsigned long parent_ip, > > if (unlikely(kprobe_running())) {
Off topic for this patch, but Masami, what's the purpose of not calling the fprobe when a kprobe is running? Does that mean it has probed another kprobe?
Probably could add a comment here to explain the issue.
-- Steve
> fp->nmissed++; > - return; > + goto recursion_unlock; > } > > kprobe_busy_begin(); > __fprobe_handler(ip, parent_ip, ops, fregs); > kprobe_busy_end(); > + > +recursion_unlock: > ftrace_test_recursion_unlock(bit); > } >
| |