Lines Matching full:we
10 When taking the i_rwsem on multiple non-directory objects, we
11 always acquire the locks in order by increasing address. We'll call
16 1) read access. Locking rules: caller locks directory we are accessing.
26 parent and finds source and target. We lock both (provided they exist). If we
27 need to lock two inodes of different type (dir vs non-dir), we lock directory
28 first. If we need to lock two inodes of the same type, lock them in inode
30 NB: we might get away with locking the source (and target in exchange
53 * Lock both the source and the target provided they exist. If we
54 need to lock two inodes of different type (dir vs non-dir), we lock
55 the directory first. If we need to lock two inodes of the same type,
59 All ->i_rwsem are taken exclusive. Again, we might get away with locking
70 First of all, at any moment we have a linear ordering of the
77 attempts to acquire lock on B, A will remain the parent of B until we
83 renames will be blocked on filesystem lock and we don't start changing
84 the order until we had acquired all locks).
113 would have a contended child and we had assumed that no object is its
118 of its descendents is locked by cross-directory rename (otherwise we
121 to (2) the order hadn't changed since we had acquired filesystem lock.
122 But locking rules for cross-directory rename guarantee that we do not
135 we had acquired filesystem lock and rename() would fail with -ELOOP in that
145 children", so if we are going to introduce hybrid objects we will need