On Tue, 2025-10-14 at 14:51 +0200, Thomas Weißschuh wrote:

I can't follow here. lockdep can indicate problems, but it should not
introduce
problems on its own. So preventing the usage together with lockdep would be
the
proverbial head in the sand. If the tracepoints called by lockdep are an issue
then we would just not call into lockdep in the first place. lockdep
triggering
these tracepoints should not be an issue in practice. I don't see a
bulletproof
way to prevent a tracepoint handler from calling another tracepoint, except
maybe extending lockdep to also track that.

Forget about it, you're right. This leads to not using lockdep inside reactors
in the first place. We could even have notrace versions of the lockdep calls
(I'm not sure lockdep itself needs them), but that's getting horrid.

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.

Thoughts?

Gabriele