Lines Matching refs:of

10 The basic object the validator operates upon is a 'class' of locks.
12 A class of locks is a group of locks that are logically the same with
14 tens of thousands of) instantiations. For example a lock in the inode
15 struct is one class, while each inode has its own instantiation of that
18 The validator tracks the 'state' of lock-classes, and it tracks
24 and all subsequent uses of that lock-class will be attached to this
37 Where STATE can be either one of (kernel/locking/lockdep_states.h)
54 The bit position indicates STATE, STATE-read, for each of the states listed
62 Unused mutexes cannot be part of the cause of an error.
69 following states are exclusive, and only one of them is allowed to be
108 any rule violation between the new lock and any of the held locks.
110 When a lock-class changes its state, the following aspects of the above
126 could interrupt _any_ of the irq-unsafe or hardirq-unsafe locks, which
134 instance of the same lock-class. Such cases typically happen when there
135 is some sort of hierarchy within objects of the same type. In these
137 (defined by the properties of the hierarchy), and the kernel grabs the
138 locks in this fixed order on each of the objects.
140 An example of such an object hierarchy that results in "nested locking"
141 is that of a "whole disk" block-dev object and a "partition" block-dev
142 object; the partition is "part of" the whole device and as long as one
149 versions of the various locking primitives were added that allow you to
166 separate (sub)class for the purposes of validation.
172 Proof of 100% correctness:
175 The validator achieves perfect, mathematical 'closure' (proof of locking
177 locking sequence that occurred at least once during the lifetime of the
179 combination and timing of these locking sequences can cause any class of
187 a very unlikely constellation of tasks, irq-contexts and timings to
191 This radically decreases the complexity of locking related QA of the
194 once, to prove locking correctness - instead of having to trigger every
195 possible combination of locking interaction between CPUs, combined with
200     part of the system corrupts the state of the validator in any way.
210 The above rules require _massive_ amounts of runtime checking. If we did
212 render the system practically unusably slow. The complexity of checking
214 tens of thousands of checks for every event.
217 sequence of locks taken after each other) only once. A simple stack of
228 The validator tracks a maximum of MAX_LOCKDEP_KEYS number of lock classes.
240 	load of the module will create a new set of lock classes for
242 	classes (see below discussion of reuse of lock classes for why).
244 	the number of lock classes will eventually reach the maximum.
246 2.	Using structures such as arrays that have large numbers of
257 	The moral of this story is that you should always explicitly
267 Of course, if you do run out of lock classes, the next thing to do is
269 you the number of lock classes currently in use along with the maximum:
284 a later run of this command to identify the leakers.  This same output