[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20250125011655.449075f32f50de6fa7ff20b8@kernel.org>
Date: Sat, 25 Jan 2025 01:16:55 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Nam Cao <namcao@...utronix.de>
Cc: Steven Rostedt <rostedt@...dmis.org>, naveen@...nel.org,
anil.s.keshavamurthy@...el.com, davem@...emloft.net,
linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
john.ogness@...utronix.de
Subject: Re: kprobe on local function
On Thu, 23 Jan 2025 03:42:24 +0100
Nam Cao <namcao@...utronix.de> wrote:
> On Thu, Jan 23, 2025 at 10:48:42AM +0900, Masami Hiramatsu wrote:
> > On Wed, 22 Jan 2025 17:29:36 -0500
> > Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > > On Wed, 22 Jan 2025 08:59:39 +0100
> > > Nam Cao <namcao@...utronix.de> wrote:
> > > > I installed a kretprobe on the function "rt_mutex_slowunlock". Although the
> > > > function is called, the probe is never hit.
> > > >
> > >
> > > How did you install the kretprobe?
>
> Sorry for being unclear. I install it from within the kernel:
>
> struct kretprobe mutex_event = {
> .kp.symbol_name = "rt_mutex_slowunlock",
> .entry_handler = entry_handler,
> .handler = return_handler,
> };
>
> register_kretprobe(&mutex_event);
This is using symbol name to install kretprobe. Thus if there
are rt_mutex_slowunlock.XXX symbols are generated by the compiler,
it can not install kretprobe to those symbols.
>
> ...
> > > Have you tried "perf probe" to install the probes? That uses dwarf info to
> > > find all the functions.
> >
> > Yes, I recommend you to use `perf probe` (under tools/perf) to put kretprobes
> > on those copies. See tools/perf/Documentation/perf-probe.txt for details.
>
> So a similar solution for in-kernel code is kallsyms_on_each_match_symbol().
> But I expect register_kretprobe() to do that by itself; or at least report
> a failure if caller specifies the symbol name, but multiple symbols of the
> same name are found. Because at least to me, my code "looks correct and
> should work" but it doesn't.
Now what you could know is that the kernel does not call the
"rt_mutex_slowunlock" symbol and it may call another copied symbol. That's
a good to know right?
Note that this in-kernel kretprobe API is a low-layer API, so that user is
responsible for controlling it carefully. This kretprobe API itself does NOT
know which copy of the optimized symbols are used.
(there could be inlined instance too)
If you need to know how many copies are generated or inlined, you need to
use the debuginfo as "perf probe" tool does, which can not handled by the
kernel itself because it is too big to be loaded. That is why I made the
"perf probe" as an external tool.
Thank you,
>
> Thank you both for your replies,
> Nam
--
Masami Hiramatsu (Google) <mhiramat@...nel.org>
Powered by blists - more mailing lists