0001 .. SPDX-License-Identifier: GPL-2.0
0002
0003 ====================================================================
0004 Miscellaneous Device control operations for the autofs kernel module
0005 ====================================================================
0006
0007 The problem
0008 ===========
0009
0010 There is a problem with active restarts in autofs (that is to say
0011 restarting autofs when there are busy mounts).
0012
0013 During normal operation autofs uses a file descriptor opened on the
0014 directory that is being managed in order to be able to issue control
0015 operations. Using a file descriptor gives ioctl operations access to
0016 autofs specific information stored in the super block. The operations
0017 are things such as setting an autofs mount catatonic, setting the
0018 expire timeout and requesting expire checks. As is explained below,
0019 certain types of autofs triggered mounts can end up covering an autofs
0020 mount itself which prevents us being able to use open(2) to obtain a
0021 file descriptor for these operations if we don't already have one open.
0022
0023 Currently autofs uses "umount -l" (lazy umount) to clear active mounts
0024 at restart. While using lazy umount works for most cases, anything that
0025 needs to walk back up the mount tree to construct a path, such as
0026 getcwd(2) and the proc file system /proc/<pid>/cwd, no longer works
0027 because the point from which the path is constructed has been detached
0028 from the mount tree.
0029
0030 The actual problem with autofs is that it can't reconnect to existing
0031 mounts. Immediately one thinks of just adding the ability to remount
0032 autofs file systems would solve it, but alas, that can't work. This is
0033 because autofs direct mounts and the implementation of "on demand mount
0034 and expire" of nested mount trees have the file system mounted directly
0035 on top of the mount trigger directory dentry.
0036
0037 For example, there are two types of automount maps, direct (in the kernel
0038 module source you will see a third type called an offset, which is just
0039 a direct mount in disguise) and indirect.
0040
0041 Here is a master map with direct and indirect map entries::
0042
0043 /- /etc/auto.direct
0044 /test /etc/auto.indirect
0045
0046 and the corresponding map files::
0047
0048 /etc/auto.direct:
0049
0050 /automount/dparse/g6 budgie:/autofs/export1
0051 /automount/dparse/g1 shark:/autofs/export1
0052 and so on.
0053
0054 /etc/auto.indirect::
0055
0056 g1 shark:/autofs/export1
0057 g6 budgie:/autofs/export1
0058 and so on.
0059
0060 For the above indirect map an autofs file system is mounted on /test and
0061 mounts are triggered for each sub-directory key by the inode lookup
0062 operation. So we see a mount of shark:/autofs/export1 on /test/g1, for
0063 example.
0064
0065 The way that direct mounts are handled is by making an autofs mount on
0066 each full path, such as /automount/dparse/g1, and using it as a mount
0067 trigger. So when we walk on the path we mount shark:/autofs/export1 "on
0068 top of this mount point". Since these are always directories we can
0069 use the follow_link inode operation to trigger the mount.
0070
0071 But, each entry in direct and indirect maps can have offsets (making
0072 them multi-mount map entries).
0073
0074 For example, an indirect mount map entry could also be::
0075
0076 g1 \
0077 / shark:/autofs/export5/testing/test \
0078 /s1 shark:/autofs/export/testing/test/s1 \
0079 /s2 shark:/autofs/export5/testing/test/s2 \
0080 /s1/ss1 shark:/autofs/export1 \
0081 /s2/ss2 shark:/autofs/export2
0082
0083 and a similarly a direct mount map entry could also be::
0084
0085 /automount/dparse/g1 \
0086 / shark:/autofs/export5/testing/test \
0087 /s1 shark:/autofs/export/testing/test/s1 \
0088 /s2 shark:/autofs/export5/testing/test/s2 \
0089 /s1/ss1 shark:/autofs/export2 \
0090 /s2/ss2 shark:/autofs/export2
0091
0092 One of the issues with version 4 of autofs was that, when mounting an
0093 entry with a large number of offsets, possibly with nesting, we needed
0094 to mount and umount all of the offsets as a single unit. Not really a
0095 problem, except for people with a large number of offsets in map entries.
0096 This mechanism is used for the well known "hosts" map and we have seen
0097 cases (in 2.4) where the available number of mounts are exhausted or
0098 where the number of privileged ports available is exhausted.
0099
0100 In version 5 we mount only as we go down the tree of offsets and
0101 similarly for expiring them which resolves the above problem. There is
0102 somewhat more detail to the implementation but it isn't needed for the
0103 sake of the problem explanation. The one important detail is that these
0104 offsets are implemented using the same mechanism as the direct mounts
0105 above and so the mount points can be covered by a mount.
0106
0107 The current autofs implementation uses an ioctl file descriptor opened
0108 on the mount point for control operations. The references held by the
0109 descriptor are accounted for in checks made to determine if a mount is
0110 in use and is also used to access autofs file system information held
0111 in the mount super block. So the use of a file handle needs to be
0112 retained.
0113
0114
0115 The Solution
0116 ============
0117
0118 To be able to restart autofs leaving existing direct, indirect and
0119 offset mounts in place we need to be able to obtain a file handle
0120 for these potentially covered autofs mount points. Rather than just
0121 implement an isolated operation it was decided to re-implement the
0122 existing ioctl interface and add new operations to provide this
0123 functionality.
0124
0125 In addition, to be able to reconstruct a mount tree that has busy mounts,
0126 the uid and gid of the last user that triggered the mount needs to be
0127 available because these can be used as macro substitution variables in
0128 autofs maps. They are recorded at mount request time and an operation
0129 has been added to retrieve them.
0130
0131 Since we're re-implementing the control interface, a couple of other
0132 problems with the existing interface have been addressed. First, when
0133 a mount or expire operation completes a status is returned to the
0134 kernel by either a "send ready" or a "send fail" operation. The
0135 "send fail" operation of the ioctl interface could only ever send
0136 ENOENT so the re-implementation allows user space to send an actual
0137 status. Another expensive operation in user space, for those using
0138 very large maps, is discovering if a mount is present. Usually this
0139 involves scanning /proc/mounts and since it needs to be done quite
0140 often it can introduce significant overhead when there are many entries
0141 in the mount table. An operation to lookup the mount status of a mount
0142 point dentry (covered or not) has also been added.
0143
0144 Current kernel development policy recommends avoiding the use of the
0145 ioctl mechanism in favor of systems such as Netlink. An implementation
0146 using this system was attempted to evaluate its suitability and it was
0147 found to be inadequate, in this case. The Generic Netlink system was
0148 used for this as raw Netlink would lead to a significant increase in
0149 complexity. There's no question that the Generic Netlink system is an
0150 elegant solution for common case ioctl functions but it's not a complete
0151 replacement probably because its primary purpose in life is to be a
0152 message bus implementation rather than specifically an ioctl replacement.
0153 While it would be possible to work around this there is one concern
0154 that lead to the decision to not use it. This is that the autofs
0155 expire in the daemon has become far to complex because umount
0156 candidates are enumerated, almost for no other reason than to "count"
0157 the number of times to call the expire ioctl. This involves scanning
0158 the mount table which has proved to be a big overhead for users with
0159 large maps. The best way to improve this is try and get back to the
0160 way the expire was done long ago. That is, when an expire request is
0161 issued for a mount (file handle) we should continually call back to
0162 the daemon until we can't umount any more mounts, then return the
0163 appropriate status to the daemon. At the moment we just expire one
0164 mount at a time. A Generic Netlink implementation would exclude this
0165 possibility for future development due to the requirements of the
0166 message bus architecture.
0167
0168
0169 autofs Miscellaneous Device mount control interface
0170 ====================================================
0171
0172 The control interface is opening a device node, typically /dev/autofs.
0173
0174 All the ioctls use a common structure to pass the needed parameter
0175 information and return operation results::
0176
0177 struct autofs_dev_ioctl {
0178 __u32 ver_major;
0179 __u32 ver_minor;
0180 __u32 size; /* total size of data passed in
0181 * including this struct */
0182 __s32 ioctlfd; /* automount command fd */
0183
0184 /* Command parameters */
0185 union {
0186 struct args_protover protover;
0187 struct args_protosubver protosubver;
0188 struct args_openmount openmount;
0189 struct args_ready ready;
0190 struct args_fail fail;
0191 struct args_setpipefd setpipefd;
0192 struct args_timeout timeout;
0193 struct args_requester requester;
0194 struct args_expire expire;
0195 struct args_askumount askumount;
0196 struct args_ismountpoint ismountpoint;
0197 };
0198
0199 char path[0];
0200 };
0201
0202 The ioctlfd field is a mount point file descriptor of an autofs mount
0203 point. It is returned by the open call and is used by all calls except
0204 the check for whether a given path is a mount point, where it may
0205 optionally be used to check a specific mount corresponding to a given
0206 mount point file descriptor, and when requesting the uid and gid of the
0207 last successful mount on a directory within the autofs file system.
0208
0209 The union is used to communicate parameters and results of calls made
0210 as described below.
0211
0212 The path field is used to pass a path where it is needed and the size field
0213 is used account for the increased structure length when translating the
0214 structure sent from user space.
0215
0216 This structure can be initialized before setting specific fields by using
0217 the void function call init_autofs_dev_ioctl(``struct autofs_dev_ioctl *``).
0218
0219 All of the ioctls perform a copy of this structure from user space to
0220 kernel space and return -EINVAL if the size parameter is smaller than
0221 the structure size itself, -ENOMEM if the kernel memory allocation fails
0222 or -EFAULT if the copy itself fails. Other checks include a version check
0223 of the compiled in user space version against the module version and a
0224 mismatch results in a -EINVAL return. If the size field is greater than
0225 the structure size then a path is assumed to be present and is checked to
0226 ensure it begins with a "/" and is NULL terminated, otherwise -EINVAL is
0227 returned. Following these checks, for all ioctl commands except
0228 AUTOFS_DEV_IOCTL_VERSION_CMD, AUTOFS_DEV_IOCTL_OPENMOUNT_CMD and
0229 AUTOFS_DEV_IOCTL_CLOSEMOUNT_CMD the ioctlfd is validated and if it is
0230 not a valid descriptor or doesn't correspond to an autofs mount point
0231 an error of -EBADF, -ENOTTY or -EINVAL (not an autofs descriptor) is
0232 returned.
0233
0234
0235 The ioctls
0236 ==========
0237
0238 An example of an implementation which uses this interface can be seen
0239 in autofs version 5.0.4 and later in file lib/dev-ioctl-lib.c of the
0240 distribution tar available for download from kernel.org in directory
0241 /pub/linux/daemons/autofs/v5.
0242
0243 The device node ioctl operations implemented by this interface are:
0244
0245
0246 AUTOFS_DEV_IOCTL_VERSION
0247 ------------------------
0248
0249 Get the major and minor version of the autofs device ioctl kernel module
0250 implementation. It requires an initialized struct autofs_dev_ioctl as an
0251 input parameter and sets the version information in the passed in structure.
0252 It returns 0 on success or the error -EINVAL if a version mismatch is
0253 detected.
0254
0255
0256 AUTOFS_DEV_IOCTL_PROTOVER_CMD and AUTOFS_DEV_IOCTL_PROTOSUBVER_CMD
0257 ------------------------------------------------------------------
0258
0259 Get the major and minor version of the autofs protocol version understood
0260 by loaded module. This call requires an initialized struct autofs_dev_ioctl
0261 with the ioctlfd field set to a valid autofs mount point descriptor
0262 and sets the requested version number in version field of struct args_protover
0263 or sub_version field of struct args_protosubver. These commands return
0264 0 on success or one of the negative error codes if validation fails.
0265
0266
0267 AUTOFS_DEV_IOCTL_OPENMOUNT and AUTOFS_DEV_IOCTL_CLOSEMOUNT
0268 ----------------------------------------------------------
0269
0270 Obtain and release a file descriptor for an autofs managed mount point
0271 path. The open call requires an initialized struct autofs_dev_ioctl with
0272 the path field set and the size field adjusted appropriately as well
0273 as the devid field of struct args_openmount set to the device number of
0274 the autofs mount. The device number can be obtained from the mount options
0275 shown in /proc/mounts. The close call requires an initialized struct
0276 autofs_dev_ioct with the ioctlfd field set to the descriptor obtained
0277 from the open call. The release of the file descriptor can also be done
0278 with close(2) so any open descriptors will also be closed at process exit.
0279 The close call is included in the implemented operations largely for
0280 completeness and to provide for a consistent user space implementation.
0281
0282
0283 AUTOFS_DEV_IOCTL_READY_CMD and AUTOFS_DEV_IOCTL_FAIL_CMD
0284 --------------------------------------------------------
0285
0286 Return mount and expire result status from user space to the kernel.
0287 Both of these calls require an initialized struct autofs_dev_ioctl
0288 with the ioctlfd field set to the descriptor obtained from the open
0289 call and the token field of struct args_ready or struct args_fail set
0290 to the wait queue token number, received by user space in the foregoing
0291 mount or expire request. The status field of struct args_fail is set to
0292 the errno of the operation. It is set to 0 on success.
0293
0294
0295 AUTOFS_DEV_IOCTL_SETPIPEFD_CMD
0296 ------------------------------
0297
0298 Set the pipe file descriptor used for kernel communication to the daemon.
0299 Normally this is set at mount time using an option but when reconnecting
0300 to a existing mount we need to use this to tell the autofs mount about
0301 the new kernel pipe descriptor. In order to protect mounts against
0302 incorrectly setting the pipe descriptor we also require that the autofs
0303 mount be catatonic (see next call).
0304
0305 The call requires an initialized struct autofs_dev_ioctl with the
0306 ioctlfd field set to the descriptor obtained from the open call and
0307 the pipefd field of struct args_setpipefd set to descriptor of the pipe.
0308 On success the call also sets the process group id used to identify the
0309 controlling process (eg. the owning automount(8) daemon) to the process
0310 group of the caller.
0311
0312
0313 AUTOFS_DEV_IOCTL_CATATONIC_CMD
0314 ------------------------------
0315
0316 Make the autofs mount point catatonic. The autofs mount will no longer
0317 issue mount requests, the kernel communication pipe descriptor is released
0318 and any remaining waits in the queue released.
0319
0320 The call requires an initialized struct autofs_dev_ioctl with the
0321 ioctlfd field set to the descriptor obtained from the open call.
0322
0323
0324 AUTOFS_DEV_IOCTL_TIMEOUT_CMD
0325 ----------------------------
0326
0327 Set the expire timeout for mounts within an autofs mount point.
0328
0329 The call requires an initialized struct autofs_dev_ioctl with the
0330 ioctlfd field set to the descriptor obtained from the open call.
0331
0332
0333 AUTOFS_DEV_IOCTL_REQUESTER_CMD
0334 ------------------------------
0335
0336 Return the uid and gid of the last process to successfully trigger a the
0337 mount on the given path dentry.
0338
0339 The call requires an initialized struct autofs_dev_ioctl with the path
0340 field set to the mount point in question and the size field adjusted
0341 appropriately. Upon return the uid field of struct args_requester contains
0342 the uid and gid field the gid.
0343
0344 When reconstructing an autofs mount tree with active mounts we need to
0345 re-connect to mounts that may have used the original process uid and
0346 gid (or string variations of them) for mount lookups within the map entry.
0347 This call provides the ability to obtain this uid and gid so they may be
0348 used by user space for the mount map lookups.
0349
0350
0351 AUTOFS_DEV_IOCTL_EXPIRE_CMD
0352 ---------------------------
0353
0354 Issue an expire request to the kernel for an autofs mount. Typically
0355 this ioctl is called until no further expire candidates are found.
0356
0357 The call requires an initialized struct autofs_dev_ioctl with the
0358 ioctlfd field set to the descriptor obtained from the open call. In
0359 addition an immediate expire that's independent of the mount timeout,
0360 and a forced expire that's independent of whether the mount is busy,
0361 can be requested by setting the how field of struct args_expire to
0362 AUTOFS_EXP_IMMEDIATE or AUTOFS_EXP_FORCED, respectively . If no
0363 expire candidates can be found the ioctl returns -1 with errno set to
0364 EAGAIN.
0365
0366 This call causes the kernel module to check the mount corresponding
0367 to the given ioctlfd for mounts that can be expired, issues an expire
0368 request back to the daemon and waits for completion.
0369
0370 AUTOFS_DEV_IOCTL_ASKUMOUNT_CMD
0371 ------------------------------
0372
0373 Checks if an autofs mount point is in use.
0374
0375 The call requires an initialized struct autofs_dev_ioctl with the
0376 ioctlfd field set to the descriptor obtained from the open call and
0377 it returns the result in the may_umount field of struct args_askumount,
0378 1 for busy and 0 otherwise.
0379
0380
0381 AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD
0382 ---------------------------------
0383
0384 Check if the given path is a mountpoint.
0385
0386 The call requires an initialized struct autofs_dev_ioctl. There are two
0387 possible variations. Both use the path field set to the path of the mount
0388 point to check and the size field adjusted appropriately. One uses the
0389 ioctlfd field to identify a specific mount point to check while the other
0390 variation uses the path and optionally in.type field of struct args_ismountpoint
0391 set to an autofs mount type. The call returns 1 if this is a mount point
0392 and sets out.devid field to the device number of the mount and out.magic
0393 field to the relevant super block magic number (described below) or 0 if
0394 it isn't a mountpoint. In both cases the device number (as returned
0395 by new_encode_dev()) is returned in out.devid field.
0396
0397 If supplied with a file descriptor we're looking for a specific mount,
0398 not necessarily at the top of the mounted stack. In this case the path
0399 the descriptor corresponds to is considered a mountpoint if it is itself
0400 a mountpoint or contains a mount, such as a multi-mount without a root
0401 mount. In this case we return 1 if the descriptor corresponds to a mount
0402 point and also returns the super magic of the covering mount if there
0403 is one or 0 if it isn't a mountpoint.
0404
0405 If a path is supplied (and the ioctlfd field is set to -1) then the path
0406 is looked up and is checked to see if it is the root of a mount. If a
0407 type is also given we are looking for a particular autofs mount and if
0408 a match isn't found a fail is returned. If the located path is the
0409 root of a mount 1 is returned along with the super magic of the mount
0410 or 0 otherwise.