On Tue, Dec 6, 2022 at 12:14 AM Jiri Olsa <olsajiri@xxxxxxxxx> wrote: > > On Mon, Dec 05, 2022 at 08:00:16PM -0800, Namhyung Kim wrote: > > On Mon, Dec 5, 2022 at 4:28 AM Jiri Olsa <olsajiri@xxxxxxxxx> wrote: > > > > > > On Sat, Dec 03, 2022 at 09:58:34AM -0800, Namhyung Kim wrote: > > > > What about contention_begin? I wonder if we can disallow recursions > > > > for those in the deny list like using bpf_prog_active.. > > > > > > I was testing change below which allows to check recursion just > > > for contention_begin tracepoint > > > > > > for the reported issue we might be ok with the change that Andrii > > > suggested, but we could have the change below as extra precaution > > > > Looks ok to me. But it seems it'd add the recursion check to every > > hm, it should allocate recursion variable just for the contention_begin > tracepoint, rest should see NULL pointer Oh, right. I meant the NULL check. > > > tracepoint. Can we just change the affected tracepoints only by > > using a kind of wrapped btp->bpf_func with some macro magic? ;-) > > I tried that and the only other ways I found are: > > - add something like TRACE_EVENT_FLAGS macro and have __init call > for specific tracepoint that sets the flag > > - add extra new 'bpf_func' that checks the re-entry, but that'd mean > around 1000 extra mostly unused small functions Hmm.. ok, that's not what I want. I'm fine with the patch then. With the 'likely' change, Acked-by: Namhyung Kim <namhyung@xxxxxxxxxx> Thanks, Namhyung