[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20230411131423.37b001f7@gandalf.local.home>
Date: Tue, 11 Apr 2023 13:14:37 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: "Masami Hiramatsu (Google)" <mhiramat@...nel.org>
Cc: Mark Rutland <mark.rutland@....com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
linux-kernel@...r.kernel.org,
"Jose E . Marchesi" <jose.marchesi@...cle.com>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Sami Tolvanen <samitolvanen@...gle.com>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v3] tracepoint: Fix CFI failures with tp_sub_func
On Sat, 8 Apr 2023 23:03:44 +0900
Masami Hiramatsu (Google) <mhiramat@...nel.org> wrote:
> I think we need another stub function similar to the original patch, because
> the __tracestub_* functions are usually not called back. Even if I enabled
> the static key to enable the stub callback, if user sets another callback
> handler to the tracepoint (e.g. enable trace event on it), the __tracestub_*
> function is not called anymore.
>
> Thus I think we just pick this version and add another patch to introduce
> __probestub_* functions in macro, and fprobe on it. This new stub function is
> something like the original one so that it doesn't break CFI. And it will be
> registered to tracepoint when the new fprobe based dynamic event is enabled.
>
If we are going to add *another* stub, then no, I don't want to use it. But
I don't see why we can't use one stub for both?
What's the issue you are having?
-- Steve
Powered by blists - more mailing lists