Lines Matching refs:validator

1 Runtime locking correctness validator
10 The basic object the validator operates upon is a 'class' of locks.
18 The validator tracks the 'state' of lock-classes, and it tracks
19 dependencies between different lock-classes. The validator maintains a
30 The validator tracks lock-class usage history into 4n + 1 separate state bits:
75 The validator detects and reports lock usage that violate these
89 because this could lead to lock inversion deadlocks. (The validator
92 validator will still track all dependencies between locks.)
107 kernel: when acquiring a new lock, the validator checks whether there is
144 lock, the lock ordering is fully correct. The validator does not
148 In order to teach the validator about this correct usage model, new
165 The validator treats a lock that is taken in such a nested fashion as a
175 The validator achieves perfect, mathematical 'closure' (proof of locking
178 kernel, the validator proves it with a 100% certainty that no
185 task/context) for the validator to be able to prove correctness. (For
199 [*] assuming that the validator itself is 100% correct, and no other
200     part of the system corrupts the state of the validator in any way.
203     with the validator. We also assume that the 64-bit 'chain hash'
228 The validator tracks a maximum of MAX_LOCKDEP_KEYS number of lock classes.
238 1.	Repeated module loading and unloading while running the validator
260 One might argue that the validator should be modified to allow