Lines Matching refs:symlink
941 handling of symbolic links: the symlink stack, together with cache
947 The symlink stack
968 to concatenate them. As one symlink may easily refer to another,
976 If a symlink referred to itself either directly or through
977 intermediaries, then following the symlink can never complete
1004 lookup will never exceed that stack as, once the 40th symlink is
1027 sometimes include space for a symlink. The other common location is
1029 pathname in a symlink can be seen as the content of that symlink and
1034 construct the symlink content into that memory whenever it is needed.
1036 When the symlink is stored in the inode, it has the same lifetime as
1042 symlink is stored and it can be accessed directly whenever needed.
1044 When the symlink is stored in the page cache or elsewhere, the
1057 space to copy the symlink into can use ``GFP_ATOMIC`` to often successfully
1075 In order for the reference to each symlink to be dropped when the walk completes,
1076 whether in RCU-walk or REF-walk, the symlink stack needs to contain,
1084 This means that each entry in the symlink stack needs to hold five
1092 part of the symlink that the other fields refer to. It is the remnant
1093 to be followed once that symlink has been fully parsed.
1095 Following the symlink
1101 symlink, or is restored from the stack, so that much of the loop
1106 When a symlink is found, walk_component() calls pick_link() via step_into()
1115 the last component of a symlink itself points to a symlink, we
1116 want to pop the symlink-just-completed off the stack before pushing
1117 the symlink-just-found to avoid leaving empty path remnants that would
1120 It is most convenient to push the new symlink references onto the
1121 stack in ``walk_component()`` immediately when the symlink is found;
1123 old symlink as it walks that last component. So it is quite
1124 convenient for ``walk_component()`` to release the old symlink and pop
1126 new symlink. It is guided in this by three flags: ``WALK_NOFOLLOW`` which
1127 forbids it from following a symlink if it finds one, ``WALK_MORE``
1129 current symlink, and ``WALK_TRAILING`` which indicates that it is on the final
1131 decide whether follow it when it is a symlink and call ``may_follow_link()`` to
1141 The more obvious case is a symlink to "``/``". All symlinks starting
1143 to point to the effective filesystem root. If the symlink only
1145 so ``NULL`` is returned to indicate that the symlink can be released and
1155 something that looks like a symlink. It is really a reference to the
1165 Following the symlink in the final component
1173 callers will want to follow a symlink if one is found, and possibly
1174 apply special handling to the last component of that symlink, rather
1178 symlink.
1183 lookup_last(). If it is a symlink that needs to be followed,
1187 component of each symlink is another symlink.
1213 3. An open with O_CREAT **does** follow a symlink in the final component,
1223 open process continues on the symlink that was found.
1234 One other place where walking down a symlink can involve leaving
1240 Symlinks are different it seems. Both reading a symlink (with ``readlink()``)
1241 and looking up a symlink on the way to some other destination can
1242 update the atime on that symlink.
1253 …://git.kernel.org/cgit/linux/kernel/git/history/history.git/diff/fs/ext2/symlink.c?id=f806c6db77b8…
1306 following "``..``", following a symlink to ``/``, crossing a mount point
1307 or accessing a "``/proc/$PID/fd/$FD``" symlink (also known as a "magic
1322 ``LOOKUP_NO_SYMLINKS`` blocks all symlink traversals (including magic-links).