Em Wed, Apr 28, 2021 at 12:45:10PM -0700, Andrii Nakryiko escreveu: > On Wed, Apr 28, 2021 at 6:10 AM Arnaldo Carvalho de Melo <arnaldo.melo@xxxxxxxxx> wrote: > > Em Tue, Apr 27, 2021 at 01:38:51PM -0700, Andrii Nakryiko escreveu: > > > On Tue, Apr 27, 2021 at 5:34 AM Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote: > > > > And tools that expect to trace a function can get that information from > > > > the BTF info instead of getting some failure when trying to trace those > > > > functions, right? > > > I don't think it belongs in BTF, though. > > My thinking was that since BTF is used when tracing, one would be > > interested in knowing if some functions can't be used for that. > > > Plus there are additional limitations enforced by BPF verifier that > > > will prevent some functions to be attached. So just because the > > > function is in BTF doesn't mean it's 100% attachable. > > Well, at least we would avoid some that can't for sure be used for > > tracing. But, a bit in there is precious, so probably geting a NACK from > > the kernel should be a good enough capability query. :-) > > Tools should just silently prune things in wildcards provided by the > > user that aren't traceable, silently, and provide an error message when > > the user explicitely asks for tracing a verbotten function. > Yep, that's what I'm doing in my retsnoop tool (I both filter by > available kprobes [0], and have extra blacklist [1]). Loading kprobes > is pretty simple and fast enough, shouldn't be a problem. > [0] https://github.com/anakryiko/retsnoop/blob/master/src/mass_attacher.c#L495 > [1] https://github.com/anakryiko/retsnoop/blob/master/src/mass_attacher.c#L41 Oh my, one more tool to download, build, try, have updated, etc. Will look at it, thanks for the pointer. - Arnaldo
