Lines Matching full:lock

22 	* lock the directory we are accessing (shared)
26 	* lock the directory we are accessing (exclusive)
30 	* lock the parent (exclusive)
32 	* lock the victim (exclusive)
36 	* lock the parent (exclusive)
38 	* lock the source (exclusive; probably could be weakened to shared)
42 	* lock the parent (exclusive)
55 	* lock the filesystem
57 	* lock the parents in "ancestors first" order (exclusive). If neither is an
58 	  ancestor of the other, lock the parent of source first.
62 	* lock the subdirectories involved (exclusive), source before target.
63 	* lock the non-directories involved (exclusive), in inode pointer order.
96 and fail the lookup if it is.  Then we try to lock the filesystem and the
104 filesystem lock prevents any changes of tree topology, other than having a
107 the filesystem lock, their relationship will remain unchanged until
108 the lock is dropped.  So from the directory operations' point of view
160 It's easy to verify that operations never take a lock with rank
161 lower than that of an already held lock.
164 set of threads.  It is a cycle of several threads, each blocked on a lock
186 one directory and blocked on attempt to lock another.  That leaves
192 if all operations had been of the "lock parent, then child" sort
202 rename and everything else is of the "lock parent, then child" sort.
205 Dn and blocked on attempt to lock D1, which is a parent of D2, which is
209 has acquired filesystem lock and verified that directories involved have
241 suppose the parents are initially in different trees; we would lock the
242 parent of source, then try to lock the parent of target, only to have
245 rename holding the lock on parent of source and trying to lock its