Lines Matching refs:we
5 When taking the i_rwsem on multiple non-directory objects, we
11 1) read access. Locking rules: caller locks directory we are accessing.
24 lock it. If we need to lock both, lock them in inode pointer order.
26 NB: we might get away with locking the the source (and target in exchange
47 lock it. If we need to lock both, do so in inode pointer order.
49 All ->i_rwsem are taken exclusive. Again, we might get away with locking
59 First of all, at any moment we have a partial ordering of the
65 attempts to acquire lock on B, A will remain the parent of B until we
71 renames will be blocked on filesystem lock and we don't start changing
72 the order until we had acquired all locks).
101 would have a contended child and we had assumed that no object is its
106 of its descendents is locked by cross-directory rename (otherwise we
109 to (2) the order hadn't changed since we had acquired filesystem lock.
110 But locking rules for cross-directory rename guarantee that we do not
123 we had acquired filesystem lock and rename() would fail with -ELOOP in that
133 children", so if we are going to introduce hybrid objects we will need