Lines Matching full:but
29 will allow us to review "REF-walk" and "RCU-walk" separately. But we
51 component, but that isn't always accurate: a pathname can lack both
53 generally forbidden in POSIX, but some of those "xxx``at``" system calls
66 not), but it might not even exist: neither the empty pathname nor the
75 ways that would lead to correct results, but not always. In
155 as heavy-handed as in the old "big kernel lock" days, but certainly not
211 but it first tries a more lightweight approach. As seen in
232 from happening, but only to detect when it happens.
254 memory pressure. This uses ``d_lock``, but ``i_rwsem`` plays no role.
318 uses CPU-local memory, but checking if the count is zero is expensive as
321 unmount operations, but does not prevent a "lazy" unmount. So holding
327 reference to the mounted dentry, but not the mounted-on dentry.
354 Finally the global (but extremely lightweight) RCU read lock is held
431 "``lookup_fast()``" which only looks in the dcache, but will ask the
447 seem obvious, but is worth pointing out so that we will recognize its
486 focuses on those symbolic links. "``do_last()``" will sometimes, but
519 tree, but a few notes specifically related to path lookup are in order
567 communicate with server processes etc. but it should ultimately either
611 principle, but then it is really designed to work when there may well
615 parts of the filesystem tree, but in many parts it will be. For the
619 Pathname lookup always starts in RCU-walk mode but only remains there
654 REF-walk, but will never then try to switch back to RCU-walk. Places
667 invalidated in one way or another, but the memory will not be
697 ``read_seqcount_retry()`` not only checks the sequence number, but also
707 instead. Notably it does _not_ use ``read_seqcount_retry()``, but
720 it for that too, but for quite a bit more.
764 somewhat unusual, but certainly possible, circumstance where the
820 have proceeded successfully, but the next step is problematic. This
845 already have one (often indirectly through another object), but it
875 knows not to sleep, but to return ``-ECHILD`` if it cannot complete
887 *is* passed the dentry but does not have access to the ``inode`` or the
952 important, but they can of course be kept separately; there is no need
964 detected without imposing limits, but limits are the simplest solution
972 true loops, but also to "very deep" non-loops. It's not about memory
981 further limit of eight on the maximum depth of recursion, but that was
993 this stack, but we need a bit more. To see that, we need to move on to
1040 but that isn't necessarily a big cost and it is better than dropping
1089 half a page. So it might seem like a lot, but is by no means
1151 The other case involves things in ``/proc`` that look like symlinks but
1163 a string name, but instead calls ``nd_jump_link()`` which updates the
1203 but a few highlights should help those interested in exploring the
1228 ``O_EXCL`` is set but otherwise is handled for an O_CREAT open much
1239 reference (or even a memory allocation) may be needed. But these
1311 it had the right name but for some other reason. This happens when
1329 anyway, but operations like ``stat()`` deliberately don't. ``statfs()``
1330 needs to trigger the mount but otherwise behaves a lot like ``stat()``, so
1334 ``LOOKUP_FOLLOW`` has a similar function to ``LOOKUP_AUTOMOUNT`` but for
1338 ``WALK_GET`` that we already met, but it is used in a different way.
1345 ``LOOKUP_RENAME_TARGET`` are not used directly by the VFS but are made
1349 These flags were previously useful for ``->lookup()`` too but with the
1357 than even a couple of releases ago. But that doesn't mean it is