Re: [PATCH v2 10/15] tools/rv: Add BPF monitors

[Gabriele Monaco <gmonaco@redhat.com>]

On Thu, 2026-10-22 at 10:21 +0206, John Ogness wrote:
> On 2026-10-22, Gabriele Monaco <gmonaco@redhat.com> wrote:
> > > I am wondering if coexistence should be the goal. For example, the
> > > monitor classes (DA, LTL, HTA) are only implemented in the kernel and
> > > provide kfuncs for the state transition functions to be available to BPF
> > > monitors. I would expect that this would allow BPF monitors to have the
> > > full functionality as in-kernel monitors, since the events, errors, and
> > > reactors would all trigger from the monitor class code.
> > 
> > Well, this would be yet another hybrid requiring BPF monitors registration
> > in the kernel like I proposed in the RFC [1], which was the main point of
> > contention (that fully shared reactors and sysfs interface, by the way).
> 
> I think there is a difference, because the registration could be via
> kfunc interface rather than requiring kernel patches. Similarly, the
> kernel is able to load drivers that it does not know about it advance.

Adding kfuncs requires a kernel patch nonetheless.

We avoid a STRUCT_OPS and craft our own way to register BPF monitors, but I
don't see a practical difference.

> > For this I would argue, though, that such monitors would be BPF just
> > on paper, we wouldn't be able to use many advantages BPF provides
> > (e.g. BPF maps).
> 
> It seems to me that your main motivation of BPF is to move the
> RV-machinery into BPF. For example, moving include/rv/ltl_monitor.h into
> BPF. But that code should not require the flexibility that BPF
> offers. It is the monitors themselves that I think benefit from BPF. For
> example, kernel/trace/rv/monitors/wakeup/wakeup.c
> 
> I do not understand why you would call it BPF on paper, when the
> semantics of the states and transitions is all coded in BPF. Everything
> that makes two monitors using the same monitor class different from each
> other. Only the generic state machine (with its tracepoints for events
> and errors) and calling of reactors is in the kernel.

Alright, that applies slightly differently to LTL, which has actual functions
inside the monitor header. For DA monitors the monitor header contains enums and
a "function" field which is essentially a matrix.

Functions like ltl_atom_update() , ltl_validate(), etc., the actual monitor
class logic is shared in the ltl header. Those are the things that I'd also have
in BPF (and share when possible, see more later).

I say BPF on paper because the monitor state and everything it stores is in the
kernel.

BPF maps offer some flexibility and stability that is actually useful, I crafted
the per-obj thing myself and I'm sure there are more bugs than a simple BPF
hashmap.
per-task monitors use a static field inside a task_struct, we have a limited
number of those and obviously the size is fixed. This is great for use-cases
where verifying the code matters (i.e. can't use malloc), but a dynamic approach
as the one BPF offers rather simply can be useful for monitors that need to
store something else. The hack used in [1] could be simplified drastically using
a BPF map.

> > The current implementation already shares the header with in-kernel
> > monitors, so the actual logic is shared.
> 
> When you say "shared" you really mean "copied". If it was "shared" (in
> the kernel) then the whole tracepoint/reactor topic would nearly solve
> itself.

Half and half, I say shared because I include the exact same header, not a copy
of it. Then some things down the path cannot be represented in BPF (tracepoints)
so I re-define these.

The logic that translates the DA function[curr_state][event] to an actual
transition is shared.

> > Besides, we'd need to be extra careful on controlling the callers. Right now
> > handlers are static, so it's easier to make sure no rogue caller messes up
> > with monitoring.
> 
> That problem is orthogonal. But I expect kfunc flags, capabilities,
> and/or signed BPF objects will be the direction to take.
> 
> The reason for my suggestion of a "true" hybrid approach is because I
> feel like you were trying to completely relocate RV to BPF, and now due
> to the tracepoint/reactor requirements, we're trying to find some hacks
> to somehow make it work good enough.
> 
> I was suggesting to take a step back and consider an approach where
> there are in-kernel pieces to leverage the benefits of in-kernel
> (generic state machine, tracepoints, reactors) and BPF pieces to
> leverage the benefits of BPF (freedom to define the semantics of states
> and transitions for any domain-specific monitor).

I'm going to consider what this implies when I get back working on this, but it
still feels cleaner to me creating kfuncs for tracing only, if we consider
bpf_printk a hack.

Exporting all handlers functions is probably going to require a significant
redesign of the current RV internals.
Handlers have access to the monitor headers (everything is static/inlined),
kfuncs wouldn't.

Thanks,
Gabriele

[1] -
https://lore.kernel.org/all/96c7ee8abbe9b9b840ca6e112744b5c74f0e9b8f.1791745088.git.wen.yang@linux.dev