On Mon, 2025-10-06 at 12:10 +0200, Thomas Weißschuh wrote:

Hi Gabriele,

quoted

Well, many use cases might be better off with tracepoints, but reactors do
things tracepoints cannot really do.
Printk is much faster (and perhaps more reliable) than the trace buffer for
printing, panic can be used to gather a kernel dump.
One may just attach to tracepoints via libtracefs/BPF and do most of the
things you'd want to do with a new reactor, but I see reactors much easier
to use from scripts, for instance.

LTLs don't benefit as much as they don't print any additional information
via reactors, but DA/HA give hints on what's wrong.

I wouldn't get rid of reactors until they become a huge maintenance burden,
but probably we could think about it twice before extending or making them
more complex.

The existing reactors could be implemented on top of the tracepoints.
This should make the RV core a bit simpler.

Note: The current interface between the RV core and the reactors is
inflexible.
Passing only opaque varargs requires all reactors to format the string from
within the tracepoint handler, as they can not know how long the objects
referenced by the varargs are valid. Passing the actual objects would allow
for example the signal reactor to format its message as part of the task_work
handler instead of the signal handler and avoid the allocation of a fixed size
message buffer.

Yeah that's right current reactors don't really make sense for things that are
not printing. But as mentioned before, fitting this for all the different
monitors types (per-cpu/per-task or something more exotic) and model types (DA
or LTL) has its challenges.

I personally never really used the panic reactor to get a crash dump, but I'd
probably miss the printk one, since it's much faster than waiting for the
tracepoint stuff (at least when matching with other things on the ringbuffer).

As I get it, extending the reactors integration to support more things might not
be too useful, but I'm not too convinced on removing reactors for good.
I'm gonna give a little more thought on this one.

quoted

For instance, what's the exact use case of the signal reactor? Isn't it
simpler
to do everything in BPF? Is the signal needed at all or something else (e.g.
perf) would do the job?

The signal reactor is convenient to write automated tests. It can be used to
validate the monitors by triggering known-bad systemcalls from a test
executable and expect it to be killed with the reactor signal, see below for
an example.
On the other hand it can be used to validate that the kernel itself does not
regress with respect to RV-validated properties. For example the test program
can enable the rtapp monitor and run an example RT application using all kinds
of known-good IPC mechanisms without it being killed.

Yeah, what I meant is: having a signal isn't your goal. Easily understand if
there was a reaction is.
You could even restructure your test using tracepoints without any signal.

So if I get it correctly, you are both "voting" for removing reactors in favour
of tracepoint-only error reporting.
Am I getting this right?

Thanks,
Gabriele