Re: [BUGFIX PATCH] tracing/kprobes: Fix to check notrace function with correct range
From: Steven Rostedt
Date: Wed Aug 22 2018 - 08:58:16 EST
On Tue, 21 Aug 2018 09:42:49 -0400
Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> On Tue, 21 Aug 2018 22:04:57 +0900
> Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote:
>
> > Fix within_notrace_func() to check notrace function correctly.
> >
> > Since the ftrace_location_range(start, end) function checks
> > the range inclusively (start <= ftrace-loc <= end), the end
> > address must not include the entry address of next function.
> >
> > However, within_notrace_func() uses kallsyms_lookup_size_offset()
> > to get the function size and calculate the end address from
> > adding the size to the entry address. This means the end address
> > is the entry address of the next function.
> >
> > In the result, within_notrace_func() fails to find notrace
> > function if the next function of the target function is
> > ftraced.
> >
> > Let's subtract 1 from the end address so that ftrace_location_range()
> > can check it correctly.
> >
> > Fixes: commit 45408c4f9250 ("tracing: kprobes: Prohibit probing on notrace function")
> > Signed-off-by: Masami Hiramatsu <mhiramat@xxxxxxxxxx>
> > Reported-by: Michael Rodin <michael@xxxxxxxxxxxx>
> > ---
> >
>
> Applied. Thanks Masami! I'll start testing this and send it upstream
> when it's finished.
>
Hmm, this fix shows the extent of not tracing functions with notrace
attched much deeper. For one thing, we can't hook kprobes to the
__schedule() function (which is now what all the main schedule
functions call). One of my tests used this function to test kprobes and
it failed.
I'll push this to Linus, but I'm wondering if we want to perhaps add a
white list of functions marked "notrace" but still kprobes can trace?
-- Steve