Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 23 Mar 2023 16:32:51 +0000 | From | Mark Rutland <> | Subject | Re: [PATCH] tracepoint: Fix CFI failures with tp_stub_func |
| |
On Thu, Mar 23, 2023 at 12:26:50PM -0400, Steven Rostedt wrote: > On Thu, 23 Mar 2023 08:53:21 -0400 > Steven Rostedt <rostedt@goodmis.org> wrote: > > > > --- a/include/linux/tracepoint.h > > > +++ b/include/linux/tracepoint.h > > > @@ -303,6 +303,7 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p) > > > __section("__tracepoints_strings") = #_name; \ > > > extern struct static_call_key STATIC_CALL_KEY(tp_func_##_name); \ > > > int __traceiter_##_name(void *__data, proto); \ > > > + void __tracestub_##_name(void *, proto); \ > > > struct tracepoint __tracepoint_##_name __used \ > > > __section("__tracepoints") = { \ > > > .name = __tpstrtab_##_name, \ > > > @@ -310,6 +311,7 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p) > > > .static_call_key = &STATIC_CALL_KEY(tp_func_##_name), \ > > > .static_call_tramp = STATIC_CALL_TRAMP_ADDR(tp_func_##_name), \ > > > .iterator = &__traceiter_##_name, \ > > > + .stub = &__tracestub_##_name, \ > > > .regfunc = _reg, \ > > > .unregfunc = _unreg, \ > > > .funcs = NULL }; \ > > > @@ -330,6 +332,9 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p) > > > } \ > > > return 0; \ > > > } \ > > > + void __tracestub_##_name(void *__data, proto) \ > > > + { \ > > > + } \ > > > > I purposely did not do this because this adds over a thousand stub > > functions! It adds one for *every* tracepoint (and that is a superset of > > trace events). > > And the commit that added this code: > > befe6d946551 ("tracepoint: Do not fail unregistering a probe due to memory failure") > > Has this in the change log: > > [ Note, this version does use undefined compiler behavior (assuming that > a stub function with no parameters or return, can be called by a location > that thinks it has parameters but still no return value. Static calls > do the same thing, so this trick is not without precedent. > > There's another solution that uses RCU tricks and is more complex, but > can be an alternative if this solution becomes an issue. > > Link: https://lore.kernel.org/lkml/20210127170721.58bce7cc@gandalf.local.home/ > ]
FWIW, I'd be happy with that approach too -- we just happened to race with our last replies. :)
Mark.
| ![\](/images/icornerr.gif) |