Message-ID: <2536a7777eb54ede40a335fa4204e87301b13040.camel@redhat.com>
Date: Mon, 06 Oct 2025 17:19:24 +0200
From: Gabriele Monaco <gmonaco@...hat.com>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
Cc: Nam Cao <namcao@...utronix.de>, linux-kernel@...r.kernel.org, 
	linux-trace-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>, 
 Masami Hiramatsu <mhiramat@...nel.org>, Mathieu Desnoyers
 <mathieu.desnoyers@...icios.com>
Subject: Re: [PATCH] rv: Add signal reactor

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

Powered by blists - more mailing lists