On Thu, Jun 08, 2023 at 04:55:40PM -0700, Andrii Nakryiko wrote: > On Thu, Jun 8, 2023 at 4:27 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > > On Thu, 8 Jun 2023 15:43:03 -0700 > > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > On Thu, Jun 8, 2023 at 2:26 PM Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > > > > > > > > > > > hi, > > > > when ftrace based tracers we need to cross check available_filter_functions > > > > with /proc/kallsyms. For example for kprobe_multi bpf link (based on fprobe) > > > > we need to make sure that symbol regex resolves to traceable symbols and > > > > that we get proper addresses for them. > > > > I forgot, what was the problem with doing the above? > > More code, more memory, more CPU to parse all the text files. Parsing > kallsyms is quite expensive, so avoiding this would be great. yes, reading both kallsyms and available_filter_functions parsing often shows up in perf profiles > > > > > > > > > > > Looks like on the last last LSF/MM/BPF there was an agreement to add new > > > > file that will have available_filter_functions symbols plus addresses. > > > > > > > > This RFC is to kick off the discussion, I'm not sure Steven wants to do > > > > that differently ;-) > > > > I'm not totally against this, but I'd like to know the full issue its > > solving. Perhaps I need to know more about what is being done, and what is > > needed too. > > There are BPF tools that allow user to specify regex/glob of kernel > functions to attach to. This regex/glob is checked against > available_filter_functions to check which functions are traceable. All > good. But then also it's important to have corresponding memory > addresses for selected functions (for many reasons, e.g., to have > non-ambiguous and fast attachment by address instead of by name, or > for some post-processing based on captured IP addresses, etc). And > that means that now we need to also parse /proc/kallsyms and > cross-join it with data fetched from available_filter_functions. > > All this is unnecessary if avalable_filter_functions would just > provide function address in the first place. It's a huge > simplification. And saves memory and CPU. > > > > > > > > > > > thanks, > > > > jirka > > > > > > > > > > > > --- > > > > Adding new available_filter_functions_addrs file that shows all available > > > > functions (same as available_filter_functions) together with addresses, > > > > like: > > > > > > > > # cat available_filter_functions_addrs | head > > > > > > nit: can we have some more succinct name, like "traceable_funcs" or > > > > > > It's to match avaliable_filter_functions > > it's minor, I'm fine with whatever name, I'm searching for it in my > history every single time anyways :) > > > > > Another way is to add a tracing option to make the address show up in the > > available_filter_functions file. That would be my preferred choice. > > > > echo 1 > options/available_filter_addrs > > > > Or something like that. > > This would modify behavior for entire system, right? I think this is > very bad. Just because one application is aware of this option and > wants to turn this on, doesn't mean that all other applications that > might also use available_filter_functions should immediately break on > that machine. > > Please, let's have a separate file. There is no downside to that. +1 for file, AFAIU the option would change that globaly so we could race with another app and break each other jirka
