linux-kernel - Re: [PATCH] rv: Add signal reactor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <3c55441187b869b5bb07b74ef88c10bfd51f9fb1.camel@redhat.com>
Date: Fri, 03 Oct 2025 08:30:10 +0200
From: Gabriele Monaco <gmonaco@...hat.com>
To: Nam Cao <namcao@...utronix.de>
Cc: Thomas Weißschuh <thomas.weissschuh@...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

2025-10-02T14:56:23Z Nam Cao <namcao@...utronix.de>:

> Thomas Weißschuh <thomas.weissschuh@...utronix.de> writes:
>> I am wondering if it would make sense to add a new tracepoint that
>> fires in addition of the reactors. That would allow multiple
>> simultaneous consumers and also bespoke handlers in userspace.
>
> We do have tracepoints for each monitor in: kernel/trace/rv/rv_trace.h
>
> And yeah, I think it is a nice idea for all the consumers to use these
> tracepoints intead (that includes rtapp testing, and also the existing
> reactors). It would simplify things, as the monitors do not have to
> worry about the reactors, they only need to invoke tracepoints.
>
> But this also makes me think about the necessity of the existing
> reactors. What do they offer that tracepoints do not? Myself I almost
> never use the reactors, so I'm thinking about removing them. But maybe
> @Gabriele has objections?

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.

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?

Thoughts?

Gabriele