Re: [PATCH] libbpf: kprobe.multi: Filter with blacklist and available_filter_functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 23, 2023 at 11:22:46AM -0700, Andrii Nakryiko wrote:

SNIP

> > > +avail_filter:
> > > +     f = fopen("/sys/kernel/debug/tracing/available_filter_functions", "r");
> > > +     if (!f)
> > > +             return true;
> > > +
> > > +     while (true) {
> > > +             ret = fscanf(f, "%s%*[^\n]\n", sym_name);
> > > +             if (ret == EOF && feof(f))
> > > +                     break;
> > > +             if (ret != 1)
> > > +                     break;
> > > +             if (!strcmp(name, sym_name)) {
> > > +                     fclose(f);
> > > +                     return true;
> > > +             }
> > > +     }
> > > +     fclose(f);
> > > +     return false;
> > > +}
> > > +
> > >  static int
> > >  resolve_kprobe_multi_cb(unsigned long long sym_addr, char sym_type,
> > >                       const char *sym_name, void *ctx)
> > > @@ -10431,6 +10475,9 @@ resolve_kprobe_multi_cb(unsigned long long sym_addr, char sym_type,
> > >       if (!glob_match(sym_name, res->pattern))
> > >               return 0;
> > >
> > > +     if (!filter_available_function(sym_name))
> > > +             return 0;
> >
> > I think it'd be better to parse available_filter_functions directly
> > for kprobe_multi instead of filtering out kallsyms entries
> 
> yep, available_filter_functions should be cheaper to parse than
> kallsyms. We can probably fallback to kallsyms still, if
> available_filter_functions are missing.
> 
> Furthermore, me and Steven chatted at lsfmm2023 about having an
> available_filter_functions-like file with kernel function addresses
> (not just names), which would speed up attachment as well. It could be
> useful in some other scenarios as well (e.g., I think retsnoop has to
> join kallsyms and available_filter_functions). I think it's still a
> good idea to add this new file, given kernel has all this information
> readily available anyways.

yes, would be useful for this, and likely in other places

jirka

> 
> 
> >
> > we could add libbpf_available_filter_functions_parse function with
> > similar callback to go over available_filter_functions file
> 
> or iterator ;)
> 
> but either way, current approach will do linear scan for each matched
> function, which is hugely inefficient, so definitely a no go
> 
> >
> >
> > jirka
> >
> > > +
> > >       err = libbpf_ensure_mem((void **) &res->addrs, &res->cap, sizeof(unsigned long),
> > >                               res->cnt + 1);
> > >       if (err)
> > > --
> > > 2.25.1
> > >
> > >




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux