• Home
  • Raw
  • Download

Lines Matching full:symlink

787 permissions.  Symlink handling requires a validated inode pointer too.
942 handling of symbolic links: the symlink stack, together with cache
948 The symlink stack
969 to concatenate them. As one symlink may easily refer to another,
977 If a symlink referred to itself either directly or through
978 intermediaries, then following the symlink can never complete
1005 lookup will never exceed that stack as, once the 40th symlink is
1028 sometimes include space for a symlink. The other common location is
1030 pathname in a symlink can be seen as the content of that symlink and
1035 construct the symlink content into that memory whenever it is needed.
1037 When the symlink is stored in the inode, it has the same lifetime as
1043 symlink is stored and it can be accessed directly whenever needed.
1045 When the symlink is stored in the page cache or elsewhere, the
1058 space to copy the symlink into can use ``GFP_ATOMIC`` to often successfully
1076 This need to drop the reference to a symlink adds significant
1080 keeping the ``struct path`` of the symlink is easiest. For RCU-walk,
1086 Finally, when providing a reference to a symlink, the filesystem also
1092 In order for the reference to each symlink to be dropped when the walk completes,
1093 whether in RCU-walk or REF-walk, the symlink stack needs to contain,
1101 This means that each entry in the symlink stack needs to hold five
1109 part of the symlink that the other fields refer to. It is the remnant
1110 to be followed once that symlink has been fully parsed.
1112 Following the symlink
1118 symlink, or is restored from the stack, so that much of the loop
1123 When a symlink is found, ``walk_component()`` returns the value ``1``
1134 the last component of a symlink itself points to a symlink, we
1135 want to pop the symlink-just-completed off the stack before pushing
1136 the symlink-just-found to avoid leaving empty path remnants that would
1139 It is most convenient to push the new symlink references onto the
1140 stack in ``walk_component()`` immediately when the symlink is found;
1142 old symlink as it walks that last component. So it is quite
1143 convenient for ``walk_component()`` to release the old symlink and pop
1145 new symlink. It is guided in this by two flags; ``WALK_GET``, which
1146 gives it permission to follow a symlink if it finds one, and
1147 ``WALK_PUT``, which tells it to release the current symlink after it has been
1160 The more obvious case is a symlink to "``/``". All symlinks starting
1162 to point to the effective filesystem root. If the symlink only
1164 so ``NULL`` is returned to indicate that the symlink can be released and
1174 something that looks like a symlink. It is really a reference to the
1185 Following the symlink in the final component
1193 callers will want to follow a symlink if one is found, and possibly
1194 apply special handling to the last component of that symlink, rather
1198 symlink.
1202 handles the final component. If the final component is a symlink
1206 each symlink is another symlink.
1209 report that it is a symlink are ``lookup_last()``, ``mountpoint_last()``
1211 ``walk_component()`` of returning ``1`` if a symlink was found that needs
1237 3. An open with O_CREAT **does** follow a symlink in the final component,
1247 open process continues on the symlink that was found.
1258 One other place where walking down a symlink can involve leaving
1264 Symlinks are different it seems. Both reading a symlink (with ``readlink()``)
1265 and looking up a symlink on the way to some other destination can
1266 update the atime on that symlink.
1277 …://git.kernel.org/cgit/linux/kernel/git/history/history.git/diff/fs/ext2/symlink.c?id=f806c6db77b8…
1330 following "``..``", following a symlink to ``/``, crossing a mount point
1331 or accessing a "``/proc/$PID/fd/$FD``" symlink (also known as a "magic
1346 ``LOOKUP_NO_SYMLINKS`` blocks all symlink traversals (including magic-links).