linux-kernel - Re: [PATCH 3/3] rv: Add explicit lockdep context for reactors

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: <20251015115714-e8e69ed8-a5e4-4139-8d6d-7f2487674e68@linutronix.de>
Date: Wed, 15 Oct 2025 12:07:55 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Gabriele Monaco <gmonaco@...hat.com>
Cc: Nam Cao <namcao@...utronix.de>, Steven Rostedt <rostedt@...dmis.org>, 
	Masami Hiramatsu <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, 
	linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] rv: Add explicit lockdep context for reactors

On Tue, Oct 14, 2025 at 04:50:18PM +0200, Gabriele Monaco wrote:
> On Tue, 2025-10-14 at 16:18 +0200, Thomas Weißschuh wrote:
> > On Tue, Oct 14, 2025 at 03:45:39PM +0200, Gabriele Monaco wrote:
> > > On Tue, 2025-10-14 at 14:51 +0200, Thomas Weißschuh wrote:

(...)

> > > Leaving for a moment concurrency quirks aside, a monitor that is reacting
> > > should be done for a while and can be marked as not monitoring before
> > > reacting, instead of after.
> > > Trace handlers triggered in the same tracepoints should, in principle, be
> > > able to tell they are not supposed to run. This at least stands for DA
> > > monitors, but the same idea could work on LTL as well.
> > > 
> > > Of course this gets more complicated in practice, but perhaps suspending
> > > monitors during reaction can be enough to allow these lockdep calls without
> > > risking infinite loops.
> > 
> > What would it mean to suspend a monitor? In my opinion we shouldn't sacrifice
> > the accuracy of the monitors or the reliability of the reactors while trying
> > to mitigate a theoretical problem.
> 
> I don't mean to really sacrifice accuracy, DA monitors are disabled after a
> reaction. This comes from the assumption that the model becomes invalid, so
> whatever comes after might be meaningless. Monitors restart as soon as we are
> sure we reached the initial state.
> In this case, it already doesn't make sense to monitor events triggered by
> reactors.
>
> LTL is a bit more complex, so it might make sense to continue monitoring just
> after a reaction, but I'm not sure how useful that is.

Ack.

It is still possible to manually re-enable all monitors through sysfs, correct?
That is needed for the kind of testing I have in mind.

Do we still consider these hypothetical tracepoint loops a blocker for this
patch series? In my opinion the usage of lockdep does not exacerbate the risk.


Thomas