Lines Matching refs:REF
29 will allow us to review "REF-walk" and "RCU-walk" separately. But we
141 REF-walk: simple concurrency management with refcounts and spinlocks
147 pathname, and focus on the "REF-walk" approach to concurrency
154 REF-walk is fairly heavy-handed with locks and reference counts. Not
161 The locking mechanisms used by REF-walk include:
204 When looking for a name in a directory, REF-walk takes ``d_lock`` on
210 REF-walk can take ``d_lock`` to get a stable reference to ``d_parent``,
501 Apart from symbolic links, there are only two parts of the "REF-walk"
584 It is in many ways similar to REF-walk and the two share quite a bit
588 We noted that REF-walk is complex because there are numerous details
591 REF-walk. The difficulty with RCU-walk comes from a different
610 The REF-walk mechanism already described certainly doesn't follow this
617 using REF-walk.
625 REF-walk.
629 that a path walk with REF-walk would have found the same entries.
632 REF-walk could also have made if it were walking down the tree at the
634 processed with the reliable, if slightly sluggish, REF-walk. If
636 restarts from the top with REF-walk.
638 This pattern of "try RCU-walk, if that fails try REF-walk" can be
647 special flag to request "REF-walk". If either of those report the
654 REF-walk, but will never then try to switch back to RCU-walk. Places
672 As we saw above, REF-walk holds a counted reference to the current
682 decisions that REF-walk could have made), it must make the checks at
683 or near the same places that REF-walk holds the references. So, when
684 REF-walk increments a reference count or takes a spinlock, RCU-walk
686 similar function. When REF-walk decrements the count or drops the
718 We already met the ``mount_lock`` seqlock when REF-walk used it to
728 relatively rare, it is reasonable to fall back on REF-walk any time
732 sequence, whether switching to REF-walk for the rest of the path or
737 REF-walk.
740 that, had REF-walk taken counted references on each vfsmount, the
789 the old dentry which we saw in REF-walk.
801 REF-walk mode which can take whatever locks are needed.
804 any sleeping, RCU-walk doesn't bother. REF-walk uses ``rename_lock`` to
809 already drops down to REF-walk and tries again with appropriate
816 That "dropping down to REF-walk" typically involves a call to
834 attempt from the top using REF-walk.
840 it, too, aborts with ``-ECHILD``, otherwise the transition to REF-walk
897 In various places in the details of REF-walk and RCU-walk, and also in
903 then trying REF-walk, and in places where ``unlazy_walk()`` is used to
904 switch to REF-walk for the rest of the path. We also saw it earlier
910 ``mount_lock`` in REF-walk. RCU-walk doesn't make use of this pattern -
1003 it doesn't need to drop down into REF-walk.
1046 REF-walk mode in which the filesystem is allowed to sleep.
1062 ``i_op->put_link()`` inode operation can be called. In REF-walk, that
1066 RCU-walk back to REF-walk in the middle of processing nested symlinks
1077 whether in RCU-walk or REF-walk, the symlink stack needs to contain,
1080 - the ``struct path`` to provide a reference to the inode in REF-walk
1082 - the ``seq`` to allow the path to be safely switched from RCU-walk to REF-walk
1280 path walk drop down to REF-walk. All of this is handled in the
1300 to lookup: RCU-walk, REF-walk, and REF-walk with forced revalidation.