On 6/03/25 01:28, Namhyung Kim wrote: > The length of PERF_RECORD_KSYMBOL for BPF is a size of JITed code so > it'd be 0 when it's not JITed. The ksymbol is needed to symbolize the > code when it gets samples in the region but non-JITed code cannot get > samples. Thus it'd be ok to ignore them. > > Actually it caused a performance issue in the perf tools on old ARM > kernels where it can refuse to JIT some BPF codes. It ended up > splitting the existing kernel map (kallsyms). And later lookup for a > kernel symbol would create a new kernel map from kallsyms and then > split it again and again. :( > > Probably there's a bug in the kernel map/symbol handling in perf tools. > But I think we need to fix this anyway. > > Reported-by: Kevin Nomura <nomurak@xxxxxxxxxx> > Cc: Song Liu <song@xxxxxxxxxx> > Signed-off-by: Namhyung Kim <namhyung@xxxxxxxxxx> > --- > tools/perf/util/machine.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c > index 3f1faf94198dbe56..c7d27384f0736408 100644 > --- a/tools/perf/util/machine.c > +++ b/tools/perf/util/machine.c > @@ -779,6 +779,10 @@ int machine__process_ksymbol(struct machine *machine __maybe_unused, > if (dump_trace) > perf_event__fprintf_ksymbol(event, stdout); > > + /* no need to process non-JIT BPF as it cannot get samples */ > + if (event->ksymbol.len == 0) > + return 0; Are all ksymbol events BPF? Maybe it is OK for PERF_RECORD_KSYMBOL_TYPE_OOL also. Perhaps adjust the comment in that case. > + > if (event->ksymbol.flags & PERF_RECORD_KSYMBOL_FLAGS_UNREGISTER) > return machine__process_ksymbol_unregister(machine, event, > sample);
