Lines Matching full:lookup
2 Pathname lookup
7 - <https://lwn.net/Articles/649115/> Pathname lookup in Linux
8 - <https://lwn.net/Articles/649729/> RCU-walk: faster pathname lookup in Linux
15 - per-directory parallel name lookup.
18 Introduction to pathname lookup
21 The most obvious aspect of pathname lookup, which very little
96 changes that affect that lookup. One fairly extreme case is that if
100 pathname lookup is to prevent them from having damaging effects. Many
103 pathname lookup.
109 make them quickly available for lookup. Each entry (known as a
116 not used for pathname lookup, and so will not be considered here.
118 The dcache has a number of uses apart from accelerating lookup. One
232 The name-lookup process (``d_lookup()``) does *not* try to prevent this
242 check). If ``rename_lock`` is updated during the lookup and the path encounters
264 The semaphore affects pathname lookup in two distinct ways. Firstly it
265 prevents changes during lookup of a name in a directory. ``walk_component()`` uses
273 Secondly, when pathname lookup reaches the final component, it will
274 sometimes need to take an exclusive lock on ``i_rwsem`` before performing the last lookup so
275 that the required exclusion can be achieved. How path lookup chooses
299 filesystem to perform the lookup and find the matching inode. When
300 the lookup is complete, it must call ``d_lookup_done()`` which clears
362 check). If ``mount_lock`` is updated during the lookup and the path encounters
431 specific part of the filesystem, and the lookup must not be allowed to
435 "``link_path_walk()``" function, which handles the lookup of everything
507 goal of the lookup is to create something, then any value for
521 On filesystems that require it, the lookup routines will call the
526 previously isn't really. When this happens the lookup of the whole
532 lookup a name can trigger changes to how that lookup should be
535 tree, but a few notes specifically related to path lookup are in order
551 process to complete before letting the new lookup proceed and possibly
595 RCU-walk - faster pathname lookup in Linux
598 RCU-walk is another algorithm for performing pathname lookup in Linux.
634 Pathname lookup always starts in RCU-walk mode but only remains there
780 starting point of the path lookup was in part of the filesystem that
791 ``lookup_fast()`` is the only lookup routine that is used in RCU-mode,
840 It is also called from ``complete_walk()`` when the lookup has reached
842 particular flavor of lookup is used.
856 has been a success and the lookup process continues.
945 flags controlling lookup will finish the story.
975 occur in a single path lookup. The most obvious is to avoid loops.
995 at most 40 (MAXSYMLINKS) symlinks in any one path lookup. It previously imposed
1004 lookup will never exceed that stack as, once the 40th symlink is
1038 on the dentry. This means that the mechanisms that pathname lookup
1048 a page will not disappear. So for these symlinks the pathname lookup
1130 component of the lookup, so we will check userspace flag ``LOOKUP_FOLLOW`` to
1202 the filesystem provides it) to combine the final lookup with the open, or
1203 will perform the separate ``i_op->lookup()`` and ``i_op->create()`` steps
1251 care about access-time updates during pathname lookup.
1280 lookup process. Many of these are only meaningful on the final
1281 component, others reflect the current state of the pathname lookup, and some
1282 apply restrictions to all path components encountered in the path lookup.
1294 to lookup: RCU-walk, REF-walk, and REF-walk with forced revalidation.
1320 path lookup. These flags are exposed through ``openat2()``'s ``resolve`` field.
1332 lookup is determined by the first mountpoint the path lookup reaches --
1378 These flags were previously useful for ``->lookup()`` too but with the
1384 Despite its complexity, all this pathname lookup code appears to be