On Mon, 2025-10-06 at 12:10 +0200, Thomas Weißschuh wrote: > Hi Gabriele, > > > 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. > > 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
