Lines Matching refs:lock

19 the parent and finds source and target.  If target already exists, lock
20 it.  If source is a non-directory, lock it.  If that means we need to
21 lock both, lock them in inode pointer order.
24 	* lock parent
26 	* lock source
31 	* lock the filesystem
32 	* lock parents in "ancestors first" order.
38 	* If target exists, lock it.  If source is a non-directory, lock
39 	  it.  In case that means we need to lock both source and target,
56 (1) if object removal or non-cross-directory rename holds lock on A and
57     attempts to acquire lock on B, A will remain the parent of B until we
58     acquire the lock on B.  (Proof: only cross-directory rename can change
59     the parent of object and it would have to lock the parent).
61 (2) if cross-directory rename holds the lock on filesystem, order will not
63     renames will be blocked on filesystem lock and we don't start changing
68     (Proof: all operations but renames take lock on at most one
73 attempt to acquire some lock and already holds at least one lock.  Let's
74 consider the set of contended locks.  First of all, filesystem lock is
78 	By (3), any process holding a non-directory lock can only be
79 waiting on another non-directory lock with a larger address.  Therefore
80 the process holding the "largest" such lock can always make progress, and
88 operation other than cross-directory rename.  Then the lock this operation
101 to (2) the order hadn't changed since we had acquired filesystem lock.
103 try to acquire lock on descendent before the lock on ancestor.
112 rename() responsible for that would be holding filesystem lock and new parent
115 we had acquired filesystem lock and rename() would fail with -ELOOP in that