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>
