On Thu, Jan 16, 2025 at 6:20 PM Al Viro <viro@xxxxxxxxxxxxxxxxxx> 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.
