Re: kprobe not always triggering

[Masami Hiramatsu (Google) <mhiramat@kernel.org>]

Hi Daniel,

On Wed, 15 Jan 2025 17:29:34 +0100
Daniel Wagner <dwagner@suse.de> wrote:

> On Wed, Jan 15, 2025 at 10:17:15AM -0500, Steven Rostedt wrote:
> > [ Adding Masami ]
> > Is it consistently the same locations being dropped?
> 
> Yes, it is very consistent.
> 
> > There's been cases of a compiler inlining some functions for the code
> > called in the same file. If that happened, then those will likely be
> > dropped. That can be tested by adding:
> > 
> > bool noinline nvme_change_ctrl_state(struct nvme_ctrl *ctrl,
> >                 enum nvme_ctrl_state new_state) 
> > 
> > You would think it shouldn't inline it, but there's nothing in the spec
> > that says it can't do so.
> 
> This did the trick, now I see the missing state transitions.

Have you tried to use `perf probe`? Even if it is inlined, you can find them
by

 perf probe -a nvme_change_ctrl_state new_state

But perhaps, some of them are inlined with constant numbers (maybe you can
find them as nvme_change_ctrl_state.constprop.XXX in kallsyms)

If my guess is correct, it is not inlined but the constant propagation
optimization[1] has been done by the compiler.

[1] https://en.wikipedia.org/wiki/Constant_folding#Constant_propagation

IIRC, commit 66f69b219716 ("perf probe: Support DW_AT_const_value constant value")
should support this case.

Thank you,

> 
> > > The system is idle, so I hope it's not just a dropped event. Any ideas
> > > what I am doing wrong?
> > 
> > I don't think it's a dropped event. It's not busy enough. But the compiler
> > making a copy of the function (by inlining or what not) can cause something
> > like this to happen.
> 
> I didn't expect that the compiler does inlining and not inlining at the
> same time. Again what learned :)
> 
> Thanks,
> Daniel


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>