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
