Re: [LSF/MM/BPF TOPIC] time to reconsider tracepoints in the vfs?

Andrii Nakryiko
2025-01-17T18:33:39Z

On Thu, Jan 16, 2025 at 6:20 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> On Thu, Jan 16, 2025 at 01:43:39PM -0800, Andrii Nakryiko wrote:
>
> > - relative stability of tracepoints in terms of naming, semantics,
> > arguments. While not stable APIs, tracepoints are "more stable" in
> > practice due to more deliberate and strategic placement (usually), so
> > they tend to get renamed or changed much less frequently.
> >
> > So, as far as BPF is concerned, tracepoints are still preferable to
> > kprobes for something like VFS, and just because BPF can be used with
> > kprobes easily doesn't mean BPF users don't need useful tracepoints.
>
> The problem is, exact same reasons invite their use by LSM-in-BPF and
> similar projects, and once that happens, the rules regarding stability
> will bite and bite _hard_.

Not clear what you mean by "their use"... Use of tracepoint by
LSM-in-BPF? Sure, to augment information gathering, perhaps, if there
is no more suitable LSM hook. But tracepoints don't allow you to make
decisions, that's the biggest difference between LSM hooks and
tracepoints from BPF POV (IMO): LSMs allow decision making,
tracepoints are read-only.

Or you mean use of LSM hooks by BPF because they are more stable
semantically? If so, yes, sure, that's a good property. Still, neither
tracepoint nor BPF LSM hooks are truly stable APIs, and users are
prepared and expected to work around that.

So, again, from BPF and BPF users' POV, neither tracepoint nor LSM
provides or guarantees API stability (though, in practice, they are,
thankfully, pretty semantically stable, which reduces the amount of
pain, of course).

>
> And from what I've seen from the same LSM-in-BPF folks, it won't stay
> within relatively stable areas - not for long, anyway.