On Wed, 11 Jul 2018 20:40:45 -0400
Francis Deslauriers <francis.deslauri...@efficios.com> wrote:

> Le mer. 11 juill. 2018, à 15 h 56, Steven Rostedt
> <rost...@goodmis.org> a écrit :
> >
> > On Wed, 11 Jul 2018 15:34:30 -0400
> > Francis Deslauriers <francis.deslauri...@efficios.com> wrote:
> >
> > > Hi Steven,
> > > I tested it and it prevents the kernel crash I am witnessing.
> > > As for the side-effect that Masami mentioned regarding not being able to 
> > > probe
> > > function inside the trace_kprobe.c file, I suggest we move the target
> > > function in
> > > its own separate compile unit so it can be compiled with the ftrace 
> > > cflags.
> > > See patch below.
> > >
> >
> > The patch below looks fine and so does Masami's. But there's too many
> > patches within emails (not separated out). I have no idea what to
> > apply. I'm not going to apply anything that is not sent as a proper
> > patch (ie. any patch within a separate thread, like the patch below).
> >
> I will put together a proper patch set with both commits.
> 
> Masami, you mentioned: "So anyway we still need to mark those functions
> NOKPROBE_SYMBOL." in a reply. What functions were you talking about?
> ftrace_ops_assist_func? Aren't those functions covered by your
> within_notrace_func check?

Ah, I thought that we'd better to consider a "pure" kprobe without ftrace
on notrace functions. From ftrace, we can prohibit probing on notrace funcs,
but if user makes an out-of-tree kprobe module and put it on notrace funcs,
that can cause a problem (if they enable some kprobe events at same time).

Thank you,



-- 
Masami Hiramatsu <mhira...@kernel.org>

Reply via email to