1c64d3dc6SMauro Carvalho Chehab.. SPDX-License-Identifier: GPL-2.0
2c64d3dc6SMauro Carvalho Chehab
3c64d3dc6SMauro Carvalho Chehab====================================================================
4c64d3dc6SMauro Carvalho ChehabMiscellaneous Device control operations for the autofs kernel module
5c64d3dc6SMauro Carvalho Chehab====================================================================
6c64d3dc6SMauro Carvalho Chehab
7c64d3dc6SMauro Carvalho ChehabThe problem
8c64d3dc6SMauro Carvalho Chehab===========
9c64d3dc6SMauro Carvalho Chehab
10c64d3dc6SMauro Carvalho ChehabThere is a problem with active restarts in autofs (that is to say
11c64d3dc6SMauro Carvalho Chehabrestarting autofs when there are busy mounts).
12c64d3dc6SMauro Carvalho Chehab
13c64d3dc6SMauro Carvalho ChehabDuring normal operation autofs uses a file descriptor opened on the
14c64d3dc6SMauro Carvalho Chehabdirectory that is being managed in order to be able to issue control
15c64d3dc6SMauro Carvalho Chehaboperations. Using a file descriptor gives ioctl operations access to
16c64d3dc6SMauro Carvalho Chehabautofs specific information stored in the super block. The operations
17c64d3dc6SMauro Carvalho Chehabare things such as setting an autofs mount catatonic, setting the
18c64d3dc6SMauro Carvalho Chehabexpire timeout and requesting expire checks. As is explained below,
19c64d3dc6SMauro Carvalho Chehabcertain types of autofs triggered mounts can end up covering an autofs
20c64d3dc6SMauro Carvalho Chehabmount itself which prevents us being able to use open(2) to obtain a
21c64d3dc6SMauro Carvalho Chehabfile descriptor for these operations if we don't already have one open.
22c64d3dc6SMauro Carvalho Chehab
23c64d3dc6SMauro Carvalho ChehabCurrently autofs uses "umount -l" (lazy umount) to clear active mounts
24c64d3dc6SMauro Carvalho Chehabat restart. While using lazy umount works for most cases, anything that
25c64d3dc6SMauro Carvalho Chehabneeds to walk back up the mount tree to construct a path, such as
26c64d3dc6SMauro Carvalho Chehabgetcwd(2) and the proc file system /proc/<pid>/cwd, no longer works
27c64d3dc6SMauro Carvalho Chehabbecause the point from which the path is constructed has been detached
28c64d3dc6SMauro Carvalho Chehabfrom the mount tree.
29c64d3dc6SMauro Carvalho Chehab
30c64d3dc6SMauro Carvalho ChehabThe actual problem with autofs is that it can't reconnect to existing
31c64d3dc6SMauro Carvalho Chehabmounts. Immediately one thinks of just adding the ability to remount
32c64d3dc6SMauro Carvalho Chehabautofs file systems would solve it, but alas, that can't work. This is
33c64d3dc6SMauro Carvalho Chehabbecause autofs direct mounts and the implementation of "on demand mount
34c64d3dc6SMauro Carvalho Chehaband expire" of nested mount trees have the file system mounted directly
35c64d3dc6SMauro Carvalho Chehabon top of the mount trigger directory dentry.
36c64d3dc6SMauro Carvalho Chehab
37c64d3dc6SMauro Carvalho ChehabFor example, there are two types of automount maps, direct (in the kernel
38c64d3dc6SMauro Carvalho Chehabmodule source you will see a third type called an offset, which is just
39c64d3dc6SMauro Carvalho Chehaba direct mount in disguise) and indirect.
40c64d3dc6SMauro Carvalho Chehab
41c64d3dc6SMauro Carvalho ChehabHere is a master map with direct and indirect map entries::
42c64d3dc6SMauro Carvalho Chehab
43c64d3dc6SMauro Carvalho Chehab    /-      /etc/auto.direct
44c64d3dc6SMauro Carvalho Chehab    /test   /etc/auto.indirect
45c64d3dc6SMauro Carvalho Chehab
46c64d3dc6SMauro Carvalho Chehaband the corresponding map files::
47c64d3dc6SMauro Carvalho Chehab
48c64d3dc6SMauro Carvalho Chehab    /etc/auto.direct:
49c64d3dc6SMauro Carvalho Chehab
50c64d3dc6SMauro Carvalho Chehab    /automount/dparse/g6  budgie:/autofs/export1
51c64d3dc6SMauro Carvalho Chehab    /automount/dparse/g1  shark:/autofs/export1
52c64d3dc6SMauro Carvalho Chehab    and so on.
53c64d3dc6SMauro Carvalho Chehab
54c64d3dc6SMauro Carvalho Chehab/etc/auto.indirect::
55c64d3dc6SMauro Carvalho Chehab
56c64d3dc6SMauro Carvalho Chehab    g1    shark:/autofs/export1
57c64d3dc6SMauro Carvalho Chehab    g6    budgie:/autofs/export1
58c64d3dc6SMauro Carvalho Chehab    and so on.
59c64d3dc6SMauro Carvalho Chehab
60c64d3dc6SMauro Carvalho ChehabFor the above indirect map an autofs file system is mounted on /test and
61c64d3dc6SMauro Carvalho Chehabmounts are triggered for each sub-directory key by the inode lookup
62c64d3dc6SMauro Carvalho Chehaboperation. So we see a mount of shark:/autofs/export1 on /test/g1, for
63c64d3dc6SMauro Carvalho Chehabexample.
64c64d3dc6SMauro Carvalho Chehab
65c64d3dc6SMauro Carvalho ChehabThe way that direct mounts are handled is by making an autofs mount on
66c64d3dc6SMauro Carvalho Chehabeach full path, such as /automount/dparse/g1, and using it as a mount
67c64d3dc6SMauro Carvalho Chehabtrigger. So when we walk on the path we mount shark:/autofs/export1 "on
68c64d3dc6SMauro Carvalho Chehabtop of this mount point". Since these are always directories we can
69c64d3dc6SMauro Carvalho Chehabuse the follow_link inode operation to trigger the mount.
70c64d3dc6SMauro Carvalho Chehab
71c64d3dc6SMauro Carvalho ChehabBut, each entry in direct and indirect maps can have offsets (making
72c64d3dc6SMauro Carvalho Chehabthem multi-mount map entries).
73c64d3dc6SMauro Carvalho Chehab
74c64d3dc6SMauro Carvalho ChehabFor example, an indirect mount map entry could also be::
75c64d3dc6SMauro Carvalho Chehab
76c64d3dc6SMauro Carvalho Chehab    g1  \
77c64d3dc6SMauro Carvalho Chehab    /        shark:/autofs/export5/testing/test \
78c64d3dc6SMauro Carvalho Chehab    /s1      shark:/autofs/export/testing/test/s1 \
79c64d3dc6SMauro Carvalho Chehab    /s2      shark:/autofs/export5/testing/test/s2 \
80c64d3dc6SMauro Carvalho Chehab    /s1/ss1  shark:/autofs/export1 \
81c64d3dc6SMauro Carvalho Chehab    /s2/ss2  shark:/autofs/export2
82c64d3dc6SMauro Carvalho Chehab
83c64d3dc6SMauro Carvalho Chehaband a similarly a direct mount map entry could also be::
84c64d3dc6SMauro Carvalho Chehab
85c64d3dc6SMauro Carvalho Chehab    /automount/dparse/g1 \
86c64d3dc6SMauro Carvalho Chehab	/       shark:/autofs/export5/testing/test \
87c64d3dc6SMauro Carvalho Chehab	/s1     shark:/autofs/export/testing/test/s1 \
88c64d3dc6SMauro Carvalho Chehab	/s2     shark:/autofs/export5/testing/test/s2 \
89c64d3dc6SMauro Carvalho Chehab	/s1/ss1 shark:/autofs/export2 \
90c64d3dc6SMauro Carvalho Chehab	/s2/ss2 shark:/autofs/export2
91c64d3dc6SMauro Carvalho Chehab
92c64d3dc6SMauro Carvalho ChehabOne of the issues with version 4 of autofs was that, when mounting an
93c64d3dc6SMauro Carvalho Chehabentry with a large number of offsets, possibly with nesting, we needed
94c64d3dc6SMauro Carvalho Chehabto mount and umount all of the offsets as a single unit. Not really a
95c64d3dc6SMauro Carvalho Chehabproblem, except for people with a large number of offsets in map entries.
96c64d3dc6SMauro Carvalho ChehabThis mechanism is used for the well known "hosts" map and we have seen
97c64d3dc6SMauro Carvalho Chehabcases (in 2.4) where the available number of mounts are exhausted or
98c64d3dc6SMauro Carvalho Chehabwhere the number of privileged ports available is exhausted.
99c64d3dc6SMauro Carvalho Chehab
100c64d3dc6SMauro Carvalho ChehabIn version 5 we mount only as we go down the tree of offsets and
101c64d3dc6SMauro Carvalho Chehabsimilarly for expiring them which resolves the above problem. There is
102c64d3dc6SMauro Carvalho Chehabsomewhat more detail to the implementation but it isn't needed for the
103c64d3dc6SMauro Carvalho Chehabsake of the problem explanation. The one important detail is that these
104c64d3dc6SMauro Carvalho Chehaboffsets are implemented using the same mechanism as the direct mounts
105c64d3dc6SMauro Carvalho Chehababove and so the mount points can be covered by a mount.
106c64d3dc6SMauro Carvalho Chehab
107c64d3dc6SMauro Carvalho ChehabThe current autofs implementation uses an ioctl file descriptor opened
108c64d3dc6SMauro Carvalho Chehabon the mount point for control operations. The references held by the
109c64d3dc6SMauro Carvalho Chehabdescriptor are accounted for in checks made to determine if a mount is
110c64d3dc6SMauro Carvalho Chehabin use and is also used to access autofs file system information held
111c64d3dc6SMauro Carvalho Chehabin the mount super block. So the use of a file handle needs to be
112c64d3dc6SMauro Carvalho Chehabretained.
113c64d3dc6SMauro Carvalho Chehab
114c64d3dc6SMauro Carvalho Chehab
115c64d3dc6SMauro Carvalho ChehabThe Solution
116c64d3dc6SMauro Carvalho Chehab============
117c64d3dc6SMauro Carvalho Chehab
118c64d3dc6SMauro Carvalho ChehabTo be able to restart autofs leaving existing direct, indirect and
119c64d3dc6SMauro Carvalho Chehaboffset mounts in place we need to be able to obtain a file handle
120c64d3dc6SMauro Carvalho Chehabfor these potentially covered autofs mount points. Rather than just
121c64d3dc6SMauro Carvalho Chehabimplement an isolated operation it was decided to re-implement the
122c64d3dc6SMauro Carvalho Chehabexisting ioctl interface and add new operations to provide this
123c64d3dc6SMauro Carvalho Chehabfunctionality.
124c64d3dc6SMauro Carvalho Chehab
125c64d3dc6SMauro Carvalho ChehabIn addition, to be able to reconstruct a mount tree that has busy mounts,
126c64d3dc6SMauro Carvalho Chehabthe uid and gid of the last user that triggered the mount needs to be
127c64d3dc6SMauro Carvalho Chehabavailable because these can be used as macro substitution variables in
128c64d3dc6SMauro Carvalho Chehabautofs maps. They are recorded at mount request time and an operation
129c64d3dc6SMauro Carvalho Chehabhas been added to retrieve them.
130c64d3dc6SMauro Carvalho Chehab
131c64d3dc6SMauro Carvalho ChehabSince we're re-implementing the control interface, a couple of other
132c64d3dc6SMauro Carvalho Chehabproblems with the existing interface have been addressed. First, when
133c64d3dc6SMauro Carvalho Chehaba mount or expire operation completes a status is returned to the
134c64d3dc6SMauro Carvalho Chehabkernel by either a "send ready" or a "send fail" operation. The
135c64d3dc6SMauro Carvalho Chehab"send fail" operation of the ioctl interface could only ever send
136c64d3dc6SMauro Carvalho ChehabENOENT so the re-implementation allows user space to send an actual
137c64d3dc6SMauro Carvalho Chehabstatus. Another expensive operation in user space, for those using
138c64d3dc6SMauro Carvalho Chehabvery large maps, is discovering if a mount is present. Usually this
139c64d3dc6SMauro Carvalho Chehabinvolves scanning /proc/mounts and since it needs to be done quite
140c64d3dc6SMauro Carvalho Chehaboften it can introduce significant overhead when there are many entries
141c64d3dc6SMauro Carvalho Chehabin the mount table. An operation to lookup the mount status of a mount
142c64d3dc6SMauro Carvalho Chehabpoint dentry (covered or not) has also been added.
143c64d3dc6SMauro Carvalho Chehab
144c64d3dc6SMauro Carvalho ChehabCurrent kernel development policy recommends avoiding the use of the
145c64d3dc6SMauro Carvalho Chehabioctl mechanism in favor of systems such as Netlink. An implementation
146c64d3dc6SMauro Carvalho Chehabusing this system was attempted to evaluate its suitability and it was
147c64d3dc6SMauro Carvalho Chehabfound to be inadequate, in this case. The Generic Netlink system was
148c64d3dc6SMauro Carvalho Chehabused for this as raw Netlink would lead to a significant increase in
149c64d3dc6SMauro Carvalho Chehabcomplexity. There's no question that the Generic Netlink system is an
150c64d3dc6SMauro Carvalho Chehabelegant solution for common case ioctl functions but it's not a complete
151c64d3dc6SMauro Carvalho Chehabreplacement probably because its primary purpose in life is to be a
152c64d3dc6SMauro Carvalho Chehabmessage bus implementation rather than specifically an ioctl replacement.
153c64d3dc6SMauro Carvalho ChehabWhile it would be possible to work around this there is one concern
154c64d3dc6SMauro Carvalho Chehabthat lead to the decision to not use it. This is that the autofs
155c64d3dc6SMauro Carvalho Chehabexpire in the daemon has become far to complex because umount
156c64d3dc6SMauro Carvalho Chehabcandidates are enumerated, almost for no other reason than to "count"
157c64d3dc6SMauro Carvalho Chehabthe number of times to call the expire ioctl. This involves scanning
158c64d3dc6SMauro Carvalho Chehabthe mount table which has proved to be a big overhead for users with
159c64d3dc6SMauro Carvalho Chehablarge maps. The best way to improve this is try and get back to the
160c64d3dc6SMauro Carvalho Chehabway the expire was done long ago. That is, when an expire request is
161c64d3dc6SMauro Carvalho Chehabissued for a mount (file handle) we should continually call back to
162c64d3dc6SMauro Carvalho Chehabthe daemon until we can't umount any more mounts, then return the
163c64d3dc6SMauro Carvalho Chehabappropriate status to the daemon. At the moment we just expire one
164c64d3dc6SMauro Carvalho Chehabmount at a time. A Generic Netlink implementation would exclude this
165c64d3dc6SMauro Carvalho Chehabpossibility for future development due to the requirements of the
166c64d3dc6SMauro Carvalho Chehabmessage bus architecture.
167c64d3dc6SMauro Carvalho Chehab
168c64d3dc6SMauro Carvalho Chehab
169c64d3dc6SMauro Carvalho Chehabautofs Miscellaneous Device mount control interface
170c64d3dc6SMauro Carvalho Chehab====================================================
171c64d3dc6SMauro Carvalho Chehab
172c64d3dc6SMauro Carvalho ChehabThe control interface is opening a device node, typically /dev/autofs.
173c64d3dc6SMauro Carvalho Chehab
174c64d3dc6SMauro Carvalho ChehabAll the ioctls use a common structure to pass the needed parameter
175c64d3dc6SMauro Carvalho Chehabinformation and return operation results::
176c64d3dc6SMauro Carvalho Chehab
177c64d3dc6SMauro Carvalho Chehab    struct autofs_dev_ioctl {
178c64d3dc6SMauro Carvalho Chehab	    __u32 ver_major;
179c64d3dc6SMauro Carvalho Chehab	    __u32 ver_minor;
180c64d3dc6SMauro Carvalho Chehab	    __u32 size;             /* total size of data passed in
181c64d3dc6SMauro Carvalho Chehab				    * including this struct */
182c64d3dc6SMauro Carvalho Chehab	    __s32 ioctlfd;          /* automount command fd */
183c64d3dc6SMauro Carvalho Chehab
184c64d3dc6SMauro Carvalho Chehab	    /* Command parameters */
185c64d3dc6SMauro Carvalho Chehab	    union {
186c64d3dc6SMauro Carvalho Chehab		    struct args_protover		protover;
187c64d3dc6SMauro Carvalho Chehab		    struct args_protosubver		protosubver;
188c64d3dc6SMauro Carvalho Chehab		    struct args_openmount		openmount;
189c64d3dc6SMauro Carvalho Chehab		    struct args_ready		ready;
190c64d3dc6SMauro Carvalho Chehab		    struct args_fail		fail;
191c64d3dc6SMauro Carvalho Chehab		    struct args_setpipefd		setpipefd;
192c64d3dc6SMauro Carvalho Chehab		    struct args_timeout		timeout;
193c64d3dc6SMauro Carvalho Chehab		    struct args_requester		requester;
194c64d3dc6SMauro Carvalho Chehab		    struct args_expire		expire;
195c64d3dc6SMauro Carvalho Chehab		    struct args_askumount		askumount;
196c64d3dc6SMauro Carvalho Chehab		    struct args_ismountpoint	ismountpoint;
197c64d3dc6SMauro Carvalho Chehab	    };
198c64d3dc6SMauro Carvalho Chehab
199*e910c8e3SArnd Bergmann	    char path[];
200c64d3dc6SMauro Carvalho Chehab    };
201c64d3dc6SMauro Carvalho Chehab
202c64d3dc6SMauro Carvalho ChehabThe ioctlfd field is a mount point file descriptor of an autofs mount
203c64d3dc6SMauro Carvalho Chehabpoint. It is returned by the open call and is used by all calls except
204c64d3dc6SMauro Carvalho Chehabthe check for whether a given path is a mount point, where it may
205c64d3dc6SMauro Carvalho Chehaboptionally be used to check a specific mount corresponding to a given
206c64d3dc6SMauro Carvalho Chehabmount point file descriptor, and when requesting the uid and gid of the
207c64d3dc6SMauro Carvalho Chehablast successful mount on a directory within the autofs file system.
208c64d3dc6SMauro Carvalho Chehab
209c64d3dc6SMauro Carvalho ChehabThe union is used to communicate parameters and results of calls made
210c64d3dc6SMauro Carvalho Chehabas described below.
211c64d3dc6SMauro Carvalho Chehab
212c64d3dc6SMauro Carvalho ChehabThe path field is used to pass a path where it is needed and the size field
213c64d3dc6SMauro Carvalho Chehabis used account for the increased structure length when translating the
214c64d3dc6SMauro Carvalho Chehabstructure sent from user space.
215c64d3dc6SMauro Carvalho Chehab
216c64d3dc6SMauro Carvalho ChehabThis structure can be initialized before setting specific fields by using
217c64d3dc6SMauro Carvalho Chehabthe void function call init_autofs_dev_ioctl(``struct autofs_dev_ioctl *``).
218c64d3dc6SMauro Carvalho Chehab
219c64d3dc6SMauro Carvalho ChehabAll of the ioctls perform a copy of this structure from user space to
220c64d3dc6SMauro Carvalho Chehabkernel space and return -EINVAL if the size parameter is smaller than
221c64d3dc6SMauro Carvalho Chehabthe structure size itself, -ENOMEM if the kernel memory allocation fails
222c64d3dc6SMauro Carvalho Chehabor -EFAULT if the copy itself fails. Other checks include a version check
223c64d3dc6SMauro Carvalho Chehabof the compiled in user space version against the module version and a
224c64d3dc6SMauro Carvalho Chehabmismatch results in a -EINVAL return. If the size field is greater than
225c64d3dc6SMauro Carvalho Chehabthe structure size then a path is assumed to be present and is checked to
226c64d3dc6SMauro Carvalho Chehabensure it begins with a "/" and is NULL terminated, otherwise -EINVAL is
227c64d3dc6SMauro Carvalho Chehabreturned. Following these checks, for all ioctl commands except
228c64d3dc6SMauro Carvalho ChehabAUTOFS_DEV_IOCTL_VERSION_CMD, AUTOFS_DEV_IOCTL_OPENMOUNT_CMD and
229c64d3dc6SMauro Carvalho ChehabAUTOFS_DEV_IOCTL_CLOSEMOUNT_CMD the ioctlfd is validated and if it is
230c64d3dc6SMauro Carvalho Chehabnot a valid descriptor or doesn't correspond to an autofs mount point
231c64d3dc6SMauro Carvalho Chehaban error of -EBADF, -ENOTTY or -EINVAL (not an autofs descriptor) is
232c64d3dc6SMauro Carvalho Chehabreturned.
233c64d3dc6SMauro Carvalho Chehab
234c64d3dc6SMauro Carvalho Chehab
235c64d3dc6SMauro Carvalho ChehabThe ioctls
236c64d3dc6SMauro Carvalho Chehab==========
237c64d3dc6SMauro Carvalho Chehab
238c64d3dc6SMauro Carvalho ChehabAn example of an implementation which uses this interface can be seen
239c64d3dc6SMauro Carvalho Chehabin autofs version 5.0.4 and later in file lib/dev-ioctl-lib.c of the
240c64d3dc6SMauro Carvalho Chehabdistribution tar available for download from kernel.org in directory
241c64d3dc6SMauro Carvalho Chehab/pub/linux/daemons/autofs/v5.
242c64d3dc6SMauro Carvalho Chehab
243c64d3dc6SMauro Carvalho ChehabThe device node ioctl operations implemented by this interface are:
244c64d3dc6SMauro Carvalho Chehab
245c64d3dc6SMauro Carvalho Chehab
246c64d3dc6SMauro Carvalho ChehabAUTOFS_DEV_IOCTL_VERSION
247c64d3dc6SMauro Carvalho Chehab------------------------
248c64d3dc6SMauro Carvalho Chehab
249c64d3dc6SMauro Carvalho ChehabGet the major and minor version of the autofs device ioctl kernel module
250c64d3dc6SMauro Carvalho Chehabimplementation. It requires an initialized struct autofs_dev_ioctl as an
251c64d3dc6SMauro Carvalho Chehabinput parameter and sets the version information in the passed in structure.
252c64d3dc6SMauro Carvalho ChehabIt returns 0 on success or the error -EINVAL if a version mismatch is
253c64d3dc6SMauro Carvalho Chehabdetected.
254c64d3dc6SMauro Carvalho Chehab
255c64d3dc6SMauro Carvalho Chehab
256c64d3dc6SMauro Carvalho ChehabAUTOFS_DEV_IOCTL_PROTOVER_CMD and AUTOFS_DEV_IOCTL_PROTOSUBVER_CMD
257c64d3dc6SMauro Carvalho Chehab------------------------------------------------------------------
258c64d3dc6SMauro Carvalho Chehab
259c64d3dc6SMauro Carvalho ChehabGet the major and minor version of the autofs protocol version understood
260c64d3dc6SMauro Carvalho Chehabby loaded module. This call requires an initialized struct autofs_dev_ioctl
261c64d3dc6SMauro Carvalho Chehabwith the ioctlfd field set to a valid autofs mount point descriptor
262c64d3dc6SMauro Carvalho Chehaband sets the requested version number in version field of struct args_protover
263c64d3dc6SMauro Carvalho Chehabor sub_version field of struct args_protosubver. These commands return
264c64d3dc6SMauro Carvalho Chehab0 on success or one of the negative error codes if validation fails.
265c64d3dc6SMauro Carvalho Chehab
266c64d3dc6SMauro Carvalho Chehab
267c64d3dc6SMauro Carvalho ChehabAUTOFS_DEV_IOCTL_OPENMOUNT and AUTOFS_DEV_IOCTL_CLOSEMOUNT
268c64d3dc6SMauro Carvalho Chehab----------------------------------------------------------
269c64d3dc6SMauro Carvalho Chehab
270c64d3dc6SMauro Carvalho ChehabObtain and release a file descriptor for an autofs managed mount point
271c64d3dc6SMauro Carvalho Chehabpath. The open call requires an initialized struct autofs_dev_ioctl with
272c64d3dc6SMauro Carvalho Chehabthe path field set and the size field adjusted appropriately as well
273c64d3dc6SMauro Carvalho Chehabas the devid field of struct args_openmount set to the device number of
274c64d3dc6SMauro Carvalho Chehabthe autofs mount. The device number can be obtained from the mount options
275c64d3dc6SMauro Carvalho Chehabshown in /proc/mounts. The close call requires an initialized struct
276c64d3dc6SMauro Carvalho Chehabautofs_dev_ioct with the ioctlfd field set to the descriptor obtained
277c64d3dc6SMauro Carvalho Chehabfrom the open call. The release of the file descriptor can also be done
278c64d3dc6SMauro Carvalho Chehabwith close(2) so any open descriptors will also be closed at process exit.
279c64d3dc6SMauro Carvalho ChehabThe close call is included in the implemented operations largely for
280c64d3dc6SMauro Carvalho Chehabcompleteness and to provide for a consistent user space implementation.
281c64d3dc6SMauro Carvalho Chehab
282c64d3dc6SMauro Carvalho Chehab
283c64d3dc6SMauro Carvalho ChehabAUTOFS_DEV_IOCTL_READY_CMD and AUTOFS_DEV_IOCTL_FAIL_CMD
284c64d3dc6SMauro Carvalho Chehab--------------------------------------------------------
285c64d3dc6SMauro Carvalho Chehab
286c64d3dc6SMauro Carvalho ChehabReturn mount and expire result status from user space to the kernel.
287c64d3dc6SMauro Carvalho ChehabBoth of these calls require an initialized struct autofs_dev_ioctl
288c64d3dc6SMauro Carvalho Chehabwith the ioctlfd field set to the descriptor obtained from the open
289c64d3dc6SMauro Carvalho Chehabcall and the token field of struct args_ready or struct args_fail set
290c64d3dc6SMauro Carvalho Chehabto the wait queue token number, received by user space in the foregoing
291c64d3dc6SMauro Carvalho Chehabmount or expire request. The status field of struct args_fail is set to
292c64d3dc6SMauro Carvalho Chehabthe errno of the operation. It is set to 0 on success.
293c64d3dc6SMauro Carvalho Chehab
294c64d3dc6SMauro Carvalho Chehab
295c64d3dc6SMauro Carvalho ChehabAUTOFS_DEV_IOCTL_SETPIPEFD_CMD
296c64d3dc6SMauro Carvalho Chehab------------------------------
297c64d3dc6SMauro Carvalho Chehab
298c64d3dc6SMauro Carvalho ChehabSet the pipe file descriptor used for kernel communication to the daemon.
299c64d3dc6SMauro Carvalho ChehabNormally this is set at mount time using an option but when reconnecting
300c64d3dc6SMauro Carvalho Chehabto a existing mount we need to use this to tell the autofs mount about
301c64d3dc6SMauro Carvalho Chehabthe new kernel pipe descriptor. In order to protect mounts against
302c64d3dc6SMauro Carvalho Chehabincorrectly setting the pipe descriptor we also require that the autofs
303c64d3dc6SMauro Carvalho Chehabmount be catatonic (see next call).
304c64d3dc6SMauro Carvalho Chehab
305c64d3dc6SMauro Carvalho ChehabThe call requires an initialized struct autofs_dev_ioctl with the
306c64d3dc6SMauro Carvalho Chehabioctlfd field set to the descriptor obtained from the open call and
307c64d3dc6SMauro Carvalho Chehabthe pipefd field of struct args_setpipefd set to descriptor of the pipe.
308c64d3dc6SMauro Carvalho ChehabOn success the call also sets the process group id used to identify the
309c64d3dc6SMauro Carvalho Chehabcontrolling process (eg. the owning automount(8) daemon) to the process
310c64d3dc6SMauro Carvalho Chehabgroup of the caller.
311c64d3dc6SMauro Carvalho Chehab
312c64d3dc6SMauro Carvalho Chehab
313c64d3dc6SMauro Carvalho ChehabAUTOFS_DEV_IOCTL_CATATONIC_CMD
314c64d3dc6SMauro Carvalho Chehab------------------------------
315c64d3dc6SMauro Carvalho Chehab
316c64d3dc6SMauro Carvalho ChehabMake the autofs mount point catatonic. The autofs mount will no longer
317c64d3dc6SMauro Carvalho Chehabissue mount requests, the kernel communication pipe descriptor is released
318c64d3dc6SMauro Carvalho Chehaband any remaining waits in the queue released.
319c64d3dc6SMauro Carvalho Chehab
320c64d3dc6SMauro Carvalho ChehabThe call requires an initialized struct autofs_dev_ioctl with the
321c64d3dc6SMauro Carvalho Chehabioctlfd field set to the descriptor obtained from the open call.
322c64d3dc6SMauro Carvalho Chehab
323c64d3dc6SMauro Carvalho Chehab
324c64d3dc6SMauro Carvalho ChehabAUTOFS_DEV_IOCTL_TIMEOUT_CMD
325c64d3dc6SMauro Carvalho Chehab----------------------------
326c64d3dc6SMauro Carvalho Chehab
327c64d3dc6SMauro Carvalho ChehabSet the expire timeout for mounts within an autofs mount point.
328c64d3dc6SMauro Carvalho Chehab
329c64d3dc6SMauro Carvalho ChehabThe call requires an initialized struct autofs_dev_ioctl with the
330c64d3dc6SMauro Carvalho Chehabioctlfd field set to the descriptor obtained from the open call.
331c64d3dc6SMauro Carvalho Chehab
332c64d3dc6SMauro Carvalho Chehab
333c64d3dc6SMauro Carvalho ChehabAUTOFS_DEV_IOCTL_REQUESTER_CMD
334c64d3dc6SMauro Carvalho Chehab------------------------------
335c64d3dc6SMauro Carvalho Chehab
336c64d3dc6SMauro Carvalho ChehabReturn the uid and gid of the last process to successfully trigger a the
337c64d3dc6SMauro Carvalho Chehabmount on the given path dentry.
338c64d3dc6SMauro Carvalho Chehab
339c64d3dc6SMauro Carvalho ChehabThe call requires an initialized struct autofs_dev_ioctl with the path
340c64d3dc6SMauro Carvalho Chehabfield set to the mount point in question and the size field adjusted
341c64d3dc6SMauro Carvalho Chehabappropriately. Upon return the uid field of struct args_requester contains
342c64d3dc6SMauro Carvalho Chehabthe uid and gid field the gid.
343c64d3dc6SMauro Carvalho Chehab
344c64d3dc6SMauro Carvalho ChehabWhen reconstructing an autofs mount tree with active mounts we need to
345c64d3dc6SMauro Carvalho Chehabre-connect to mounts that may have used the original process uid and
346c64d3dc6SMauro Carvalho Chehabgid (or string variations of them) for mount lookups within the map entry.
347c64d3dc6SMauro Carvalho ChehabThis call provides the ability to obtain this uid and gid so they may be
348c64d3dc6SMauro Carvalho Chehabused by user space for the mount map lookups.
349c64d3dc6SMauro Carvalho Chehab
350c64d3dc6SMauro Carvalho Chehab
351c64d3dc6SMauro Carvalho ChehabAUTOFS_DEV_IOCTL_EXPIRE_CMD
352c64d3dc6SMauro Carvalho Chehab---------------------------
353c64d3dc6SMauro Carvalho Chehab
354c64d3dc6SMauro Carvalho ChehabIssue an expire request to the kernel for an autofs mount. Typically
355c64d3dc6SMauro Carvalho Chehabthis ioctl is called until no further expire candidates are found.
356c64d3dc6SMauro Carvalho Chehab
357c64d3dc6SMauro Carvalho ChehabThe call requires an initialized struct autofs_dev_ioctl with the
358c64d3dc6SMauro Carvalho Chehabioctlfd field set to the descriptor obtained from the open call. In
359c64d3dc6SMauro Carvalho Chehabaddition an immediate expire that's independent of the mount timeout,
360c64d3dc6SMauro Carvalho Chehaband a forced expire that's independent of whether the mount is busy,
361c64d3dc6SMauro Carvalho Chehabcan be requested by setting the how field of struct args_expire to
362c64d3dc6SMauro Carvalho ChehabAUTOFS_EXP_IMMEDIATE or AUTOFS_EXP_FORCED, respectively . If no
363c64d3dc6SMauro Carvalho Chehabexpire candidates can be found the ioctl returns -1 with errno set to
364c64d3dc6SMauro Carvalho ChehabEAGAIN.
365c64d3dc6SMauro Carvalho Chehab
366c64d3dc6SMauro Carvalho ChehabThis call causes the kernel module to check the mount corresponding
367c64d3dc6SMauro Carvalho Chehabto the given ioctlfd for mounts that can be expired, issues an expire
368c64d3dc6SMauro Carvalho Chehabrequest back to the daemon and waits for completion.
369c64d3dc6SMauro Carvalho Chehab
370c64d3dc6SMauro Carvalho ChehabAUTOFS_DEV_IOCTL_ASKUMOUNT_CMD
371c64d3dc6SMauro Carvalho Chehab------------------------------
372c64d3dc6SMauro Carvalho Chehab
373c64d3dc6SMauro Carvalho ChehabChecks if an autofs mount point is in use.
374c64d3dc6SMauro Carvalho Chehab
375c64d3dc6SMauro Carvalho ChehabThe call requires an initialized struct autofs_dev_ioctl with the
376c64d3dc6SMauro Carvalho Chehabioctlfd field set to the descriptor obtained from the open call and
377c64d3dc6SMauro Carvalho Chehabit returns the result in the may_umount field of struct args_askumount,
378c64d3dc6SMauro Carvalho Chehab1 for busy and 0 otherwise.
379c64d3dc6SMauro Carvalho Chehab
380c64d3dc6SMauro Carvalho Chehab
381c64d3dc6SMauro Carvalho ChehabAUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD
382c64d3dc6SMauro Carvalho Chehab---------------------------------
383c64d3dc6SMauro Carvalho Chehab
384c64d3dc6SMauro Carvalho ChehabCheck if the given path is a mountpoint.
385c64d3dc6SMauro Carvalho Chehab
386c64d3dc6SMauro Carvalho ChehabThe call requires an initialized struct autofs_dev_ioctl. There are two
387c64d3dc6SMauro Carvalho Chehabpossible variations. Both use the path field set to the path of the mount
388c64d3dc6SMauro Carvalho Chehabpoint to check and the size field adjusted appropriately. One uses the
389c64d3dc6SMauro Carvalho Chehabioctlfd field to identify a specific mount point to check while the other
390c64d3dc6SMauro Carvalho Chehabvariation uses the path and optionally in.type field of struct args_ismountpoint
391c64d3dc6SMauro Carvalho Chehabset to an autofs mount type. The call returns 1 if this is a mount point
392c64d3dc6SMauro Carvalho Chehaband sets out.devid field to the device number of the mount and out.magic
393c64d3dc6SMauro Carvalho Chehabfield to the relevant super block magic number (described below) or 0 if
394612176a4SRandy Dunlapit isn't a mountpoint. In both cases the device number (as returned
395c64d3dc6SMauro Carvalho Chehabby new_encode_dev()) is returned in out.devid field.
396c64d3dc6SMauro Carvalho Chehab
397c64d3dc6SMauro Carvalho ChehabIf supplied with a file descriptor we're looking for a specific mount,
398c64d3dc6SMauro Carvalho Chehabnot necessarily at the top of the mounted stack. In this case the path
399c64d3dc6SMauro Carvalho Chehabthe descriptor corresponds to is considered a mountpoint if it is itself
400c64d3dc6SMauro Carvalho Chehaba mountpoint or contains a mount, such as a multi-mount without a root
401c64d3dc6SMauro Carvalho Chehabmount. In this case we return 1 if the descriptor corresponds to a mount
402612176a4SRandy Dunlappoint and also returns the super magic of the covering mount if there
403c64d3dc6SMauro Carvalho Chehabis one or 0 if it isn't a mountpoint.
404c64d3dc6SMauro Carvalho Chehab
405c64d3dc6SMauro Carvalho ChehabIf a path is supplied (and the ioctlfd field is set to -1) then the path
406c64d3dc6SMauro Carvalho Chehabis looked up and is checked to see if it is the root of a mount. If a
407c64d3dc6SMauro Carvalho Chehabtype is also given we are looking for a particular autofs mount and if
408612176a4SRandy Dunlapa match isn't found a fail is returned. If the located path is the
409c64d3dc6SMauro Carvalho Chehabroot of a mount 1 is returned along with the super magic of the mount
410c64d3dc6SMauro Carvalho Chehabor 0 otherwise.
411