1 .. SPDX-License-Identifier: GPL-2.0 1 .. SPDX-License-Identifier: GPL-2.0
2 2
3 ============================================== 3 ====================================================================
4 Miscellaneous Device control operations for th 4 Miscellaneous Device control operations for the autofs kernel module
5 ============================================== 5 ====================================================================
6 6
7 The problem 7 The problem
8 =========== 8 ===========
9 9
10 There is a problem with active restarts in aut 10 There is a problem with active restarts in autofs (that is to say
11 restarting autofs when there are busy mounts). 11 restarting autofs when there are busy mounts).
12 12
13 During normal operation autofs uses a file des 13 During normal operation autofs uses a file descriptor opened on the
14 directory that is being managed in order to be 14 directory that is being managed in order to be able to issue control
15 operations. Using a file descriptor gives ioct 15 operations. Using a file descriptor gives ioctl operations access to
16 autofs specific information stored in the supe 16 autofs specific information stored in the super block. The operations
17 are things such as setting an autofs mount cat 17 are things such as setting an autofs mount catatonic, setting the
18 expire timeout and requesting expire checks. A 18 expire timeout and requesting expire checks. As is explained below,
19 certain types of autofs triggered mounts can e 19 certain types of autofs triggered mounts can end up covering an autofs
20 mount itself which prevents us being able to u 20 mount itself which prevents us being able to use open(2) to obtain a
21 file descriptor for these operations if we don 21 file descriptor for these operations if we don't already have one open.
22 22
23 Currently autofs uses "umount -l" (lazy umount 23 Currently autofs uses "umount -l" (lazy umount) to clear active mounts
24 at restart. While using lazy umount works for 24 at restart. While using lazy umount works for most cases, anything that
25 needs to walk back up the mount tree to constr 25 needs to walk back up the mount tree to construct a path, such as
26 getcwd(2) and the proc file system /proc/<pid> 26 getcwd(2) and the proc file system /proc/<pid>/cwd, no longer works
27 because the point from which the path is const 27 because the point from which the path is constructed has been detached
28 from the mount tree. 28 from the mount tree.
29 29
30 The actual problem with autofs is that it can' 30 The actual problem with autofs is that it can't reconnect to existing
31 mounts. Immediately one thinks of just adding 31 mounts. Immediately one thinks of just adding the ability to remount
32 autofs file systems would solve it, but alas, 32 autofs file systems would solve it, but alas, that can't work. This is
33 because autofs direct mounts and the implement 33 because autofs direct mounts and the implementation of "on demand mount
34 and expire" of nested mount trees have the fil 34 and expire" of nested mount trees have the file system mounted directly
35 on top of the mount trigger directory dentry. 35 on top of the mount trigger directory dentry.
36 36
37 For example, there are two types of automount 37 For example, there are two types of automount maps, direct (in the kernel
38 module source you will see a third type called 38 module source you will see a third type called an offset, which is just
39 a direct mount in disguise) and indirect. 39 a direct mount in disguise) and indirect.
40 40
41 Here is a master map with direct and indirect 41 Here is a master map with direct and indirect map entries::
42 42
43 /- /etc/auto.direct 43 /- /etc/auto.direct
44 /test /etc/auto.indirect 44 /test /etc/auto.indirect
45 45
46 and the corresponding map files:: 46 and the corresponding map files::
47 47
48 /etc/auto.direct: 48 /etc/auto.direct:
49 49
50 /automount/dparse/g6 budgie:/autofs/expor 50 /automount/dparse/g6 budgie:/autofs/export1
51 /automount/dparse/g1 shark:/autofs/export 51 /automount/dparse/g1 shark:/autofs/export1
52 and so on. 52 and so on.
53 53
54 /etc/auto.indirect:: 54 /etc/auto.indirect::
55 55
56 g1 shark:/autofs/export1 56 g1 shark:/autofs/export1
57 g6 budgie:/autofs/export1 57 g6 budgie:/autofs/export1
58 and so on. 58 and so on.
59 59
60 For the above indirect map an autofs file syst 60 For the above indirect map an autofs file system is mounted on /test and
61 mounts are triggered for each sub-directory ke 61 mounts are triggered for each sub-directory key by the inode lookup
62 operation. So we see a mount of shark:/autofs/ 62 operation. So we see a mount of shark:/autofs/export1 on /test/g1, for
63 example. 63 example.
64 64
65 The way that direct mounts are handled is by m 65 The way that direct mounts are handled is by making an autofs mount on
66 each full path, such as /automount/dparse/g1, 66 each full path, such as /automount/dparse/g1, and using it as a mount
67 trigger. So when we walk on the path we mount 67 trigger. So when we walk on the path we mount shark:/autofs/export1 "on
68 top of this mount point". Since these are alwa 68 top of this mount point". Since these are always directories we can
69 use the follow_link inode operation to trigger 69 use the follow_link inode operation to trigger the mount.
70 70
71 But, each entry in direct and indirect maps ca 71 But, each entry in direct and indirect maps can have offsets (making
72 them multi-mount map entries). 72 them multi-mount map entries).
73 73
74 For example, an indirect mount map entry could 74 For example, an indirect mount map entry could also be::
75 75
76 g1 \ 76 g1 \
77 / shark:/autofs/export5/testing/tes 77 / shark:/autofs/export5/testing/test \
78 /s1 shark:/autofs/export/testing/test 78 /s1 shark:/autofs/export/testing/test/s1 \
79 /s2 shark:/autofs/export5/testing/tes 79 /s2 shark:/autofs/export5/testing/test/s2 \
80 /s1/ss1 shark:/autofs/export1 \ 80 /s1/ss1 shark:/autofs/export1 \
81 /s2/ss2 shark:/autofs/export2 81 /s2/ss2 shark:/autofs/export2
82 82
83 and a similarly a direct mount map entry could 83 and a similarly a direct mount map entry could also be::
84 84
85 /automount/dparse/g1 \ 85 /automount/dparse/g1 \
86 / shark:/autofs/export5/testing/ 86 / shark:/autofs/export5/testing/test \
87 /s1 shark:/autofs/export/testing/t 87 /s1 shark:/autofs/export/testing/test/s1 \
88 /s2 shark:/autofs/export5/testing/ 88 /s2 shark:/autofs/export5/testing/test/s2 \
89 /s1/ss1 shark:/autofs/export2 \ 89 /s1/ss1 shark:/autofs/export2 \
90 /s2/ss2 shark:/autofs/export2 90 /s2/ss2 shark:/autofs/export2
91 91
92 One of the issues with version 4 of autofs was 92 One of the issues with version 4 of autofs was that, when mounting an
93 entry with a large number of offsets, possibly 93 entry with a large number of offsets, possibly with nesting, we needed
94 to mount and umount all of the offsets as a si 94 to mount and umount all of the offsets as a single unit. Not really a
95 problem, except for people with a large number 95 problem, except for people with a large number of offsets in map entries.
96 This mechanism is used for the well known "hos 96 This mechanism is used for the well known "hosts" map and we have seen
97 cases (in 2.4) where the available number of m 97 cases (in 2.4) where the available number of mounts are exhausted or
98 where the number of privileged ports available 98 where the number of privileged ports available is exhausted.
99 99
100 In version 5 we mount only as we go down the t 100 In version 5 we mount only as we go down the tree of offsets and
101 similarly for expiring them which resolves the 101 similarly for expiring them which resolves the above problem. There is
102 somewhat more detail to the implementation but 102 somewhat more detail to the implementation but it isn't needed for the
103 sake of the problem explanation. The one impor 103 sake of the problem explanation. The one important detail is that these
104 offsets are implemented using the same mechani 104 offsets are implemented using the same mechanism as the direct mounts
105 above and so the mount points can be covered b 105 above and so the mount points can be covered by a mount.
106 106
107 The current autofs implementation uses an ioct 107 The current autofs implementation uses an ioctl file descriptor opened
108 on the mount point for control operations. The 108 on the mount point for control operations. The references held by the
109 descriptor are accounted for in checks made to 109 descriptor are accounted for in checks made to determine if a mount is
110 in use and is also used to access autofs file 110 in use and is also used to access autofs file system information held
111 in the mount super block. So the use of a file 111 in the mount super block. So the use of a file handle needs to be
112 retained. 112 retained.
113 113
114 114
115 The Solution 115 The Solution
116 ============ 116 ============
117 117
118 To be able to restart autofs leaving existing 118 To be able to restart autofs leaving existing direct, indirect and
119 offset mounts in place we need to be able to o 119 offset mounts in place we need to be able to obtain a file handle
120 for these potentially covered autofs mount poi 120 for these potentially covered autofs mount points. Rather than just
121 implement an isolated operation it was decided 121 implement an isolated operation it was decided to re-implement the
122 existing ioctl interface and add new operation 122 existing ioctl interface and add new operations to provide this
123 functionality. 123 functionality.
124 124
125 In addition, to be able to reconstruct a mount 125 In addition, to be able to reconstruct a mount tree that has busy mounts,
126 the uid and gid of the last user that triggere 126 the uid and gid of the last user that triggered the mount needs to be
127 available because these can be used as macro s 127 available because these can be used as macro substitution variables in
128 autofs maps. They are recorded at mount reques 128 autofs maps. They are recorded at mount request time and an operation
129 has been added to retrieve them. 129 has been added to retrieve them.
130 130
131 Since we're re-implementing the control interf 131 Since we're re-implementing the control interface, a couple of other
132 problems with the existing interface have been 132 problems with the existing interface have been addressed. First, when
133 a mount or expire operation completes a status 133 a mount or expire operation completes a status is returned to the
134 kernel by either a "send ready" or a "send fai 134 kernel by either a "send ready" or a "send fail" operation. The
135 "send fail" operation of the ioctl interface c 135 "send fail" operation of the ioctl interface could only ever send
136 ENOENT so the re-implementation allows user sp 136 ENOENT so the re-implementation allows user space to send an actual
137 status. Another expensive operation in user sp 137 status. Another expensive operation in user space, for those using
138 very large maps, is discovering if a mount is 138 very large maps, is discovering if a mount is present. Usually this
139 involves scanning /proc/mounts and since it ne 139 involves scanning /proc/mounts and since it needs to be done quite
140 often it can introduce significant overhead wh 140 often it can introduce significant overhead when there are many entries
141 in the mount table. An operation to lookup the 141 in the mount table. An operation to lookup the mount status of a mount
142 point dentry (covered or not) has also been ad 142 point dentry (covered or not) has also been added.
143 143
144 Current kernel development policy recommends a 144 Current kernel development policy recommends avoiding the use of the
145 ioctl mechanism in favor of systems such as Ne 145 ioctl mechanism in favor of systems such as Netlink. An implementation
146 using this system was attempted to evaluate it 146 using this system was attempted to evaluate its suitability and it was
147 found to be inadequate, in this case. The Gene 147 found to be inadequate, in this case. The Generic Netlink system was
148 used for this as raw Netlink would lead to a s 148 used for this as raw Netlink would lead to a significant increase in
149 complexity. There's no question that the Gener 149 complexity. There's no question that the Generic Netlink system is an
150 elegant solution for common case ioctl functio 150 elegant solution for common case ioctl functions but it's not a complete
151 replacement probably because its primary purpo 151 replacement probably because its primary purpose in life is to be a
152 message bus implementation rather than specifi 152 message bus implementation rather than specifically an ioctl replacement.
153 While it would be possible to work around this 153 While it would be possible to work around this there is one concern
154 that lead to the decision to not use it. This 154 that lead to the decision to not use it. This is that the autofs
155 expire in the daemon has become far to complex 155 expire in the daemon has become far to complex because umount
156 candidates are enumerated, almost for no other 156 candidates are enumerated, almost for no other reason than to "count"
157 the number of times to call the expire ioctl. 157 the number of times to call the expire ioctl. This involves scanning
158 the mount table which has proved to be a big o 158 the mount table which has proved to be a big overhead for users with
159 large maps. The best way to improve this is tr 159 large maps. The best way to improve this is try and get back to the
160 way the expire was done long ago. That is, whe 160 way the expire was done long ago. That is, when an expire request is
161 issued for a mount (file handle) we should con 161 issued for a mount (file handle) we should continually call back to
162 the daemon until we can't umount any more moun 162 the daemon until we can't umount any more mounts, then return the
163 appropriate status to the daemon. At the momen 163 appropriate status to the daemon. At the moment we just expire one
164 mount at a time. A Generic Netlink implementat 164 mount at a time. A Generic Netlink implementation would exclude this
165 possibility for future development due to the 165 possibility for future development due to the requirements of the
166 message bus architecture. 166 message bus architecture.
167 167
168 168
169 autofs Miscellaneous Device mount control inte 169 autofs Miscellaneous Device mount control interface
170 ============================================== 170 ====================================================
171 171
172 The control interface is opening a device node 172 The control interface is opening a device node, typically /dev/autofs.
173 173
174 All the ioctls use a common structure to pass 174 All the ioctls use a common structure to pass the needed parameter
175 information and return operation results:: 175 information and return operation results::
176 176
177 struct autofs_dev_ioctl { 177 struct autofs_dev_ioctl {
178 __u32 ver_major; 178 __u32 ver_major;
179 __u32 ver_minor; 179 __u32 ver_minor;
180 __u32 size; /* total s 180 __u32 size; /* total size of data passed in
181 * includin 181 * including this struct */
182 __s32 ioctlfd; /* automou 182 __s32 ioctlfd; /* automount command fd */
183 183
184 /* Command parameters */ 184 /* Command parameters */
185 union { 185 union {
186 struct args_protover 186 struct args_protover protover;
187 struct args_protosubver 187 struct args_protosubver protosubver;
188 struct args_openmount 188 struct args_openmount openmount;
189 struct args_ready 189 struct args_ready ready;
190 struct args_fail 190 struct args_fail fail;
191 struct args_setpipefd 191 struct args_setpipefd setpipefd;
192 struct args_timeout 192 struct args_timeout timeout;
193 struct args_requester 193 struct args_requester requester;
194 struct args_expire 194 struct args_expire expire;
195 struct args_askumount 195 struct args_askumount askumount;
196 struct args_ismountpoint 196 struct args_ismountpoint ismountpoint;
197 }; 197 };
198 198
199 char path[]; 199 char path[];
200 }; 200 };
201 201
202 The ioctlfd field is a mount point file descri 202 The ioctlfd field is a mount point file descriptor of an autofs mount
203 point. It is returned by the open call and is 203 point. It is returned by the open call and is used by all calls except
204 the check for whether a given path is a mount 204 the check for whether a given path is a mount point, where it may
205 optionally be used to check a specific mount c 205 optionally be used to check a specific mount corresponding to a given
206 mount point file descriptor, and when requesti 206 mount point file descriptor, and when requesting the uid and gid of the
207 last successful mount on a directory within th 207 last successful mount on a directory within the autofs file system.
208 208
209 The union is used to communicate parameters an 209 The union is used to communicate parameters and results of calls made
210 as described below. 210 as described below.
211 211
212 The path field is used to pass a path where it 212 The path field is used to pass a path where it is needed and the size field
213 is used account for the increased structure le 213 is used account for the increased structure length when translating the
214 structure sent from user space. 214 structure sent from user space.
215 215
216 This structure can be initialized before setti 216 This structure can be initialized before setting specific fields by using
217 the void function call init_autofs_dev_ioctl(` 217 the void function call init_autofs_dev_ioctl(``struct autofs_dev_ioctl *``).
218 218
219 All of the ioctls perform a copy of this struc 219 All of the ioctls perform a copy of this structure from user space to
220 kernel space and return -EINVAL if the size pa 220 kernel space and return -EINVAL if the size parameter is smaller than
221 the structure size itself, -ENOMEM if the kern 221 the structure size itself, -ENOMEM if the kernel memory allocation fails
222 or -EFAULT if the copy itself fails. Other che 222 or -EFAULT if the copy itself fails. Other checks include a version check
223 of the compiled in user space version against 223 of the compiled in user space version against the module version and a
224 mismatch results in a -EINVAL return. If the s 224 mismatch results in a -EINVAL return. If the size field is greater than
225 the structure size then a path is assumed to b 225 the structure size then a path is assumed to be present and is checked to
226 ensure it begins with a "/" and is NULL termin 226 ensure it begins with a "/" and is NULL terminated, otherwise -EINVAL is
227 returned. Following these checks, for all ioct 227 returned. Following these checks, for all ioctl commands except
228 AUTOFS_DEV_IOCTL_VERSION_CMD, AUTOFS_DEV_IOCTL 228 AUTOFS_DEV_IOCTL_VERSION_CMD, AUTOFS_DEV_IOCTL_OPENMOUNT_CMD and
229 AUTOFS_DEV_IOCTL_CLOSEMOUNT_CMD the ioctlfd is 229 AUTOFS_DEV_IOCTL_CLOSEMOUNT_CMD the ioctlfd is validated and if it is
230 not a valid descriptor or doesn't correspond t 230 not a valid descriptor or doesn't correspond to an autofs mount point
231 an error of -EBADF, -ENOTTY or -EINVAL (not an 231 an error of -EBADF, -ENOTTY or -EINVAL (not an autofs descriptor) is
232 returned. 232 returned.
233 233
234 234
235 The ioctls 235 The ioctls
236 ========== 236 ==========
237 237
238 An example of an implementation which uses thi 238 An example of an implementation which uses this interface can be seen
239 in autofs version 5.0.4 and later in file lib/ 239 in autofs version 5.0.4 and later in file lib/dev-ioctl-lib.c of the
240 distribution tar available for download from k 240 distribution tar available for download from kernel.org in directory
241 /pub/linux/daemons/autofs/v5. 241 /pub/linux/daemons/autofs/v5.
242 242
243 The device node ioctl operations implemented b 243 The device node ioctl operations implemented by this interface are:
244 244
245 245
246 AUTOFS_DEV_IOCTL_VERSION 246 AUTOFS_DEV_IOCTL_VERSION
247 ------------------------ 247 ------------------------
248 248
249 Get the major and minor version of the autofs 249 Get the major and minor version of the autofs device ioctl kernel module
250 implementation. It requires an initialized str 250 implementation. It requires an initialized struct autofs_dev_ioctl as an
251 input parameter and sets the version informati 251 input parameter and sets the version information in the passed in structure.
252 It returns 0 on success or the error -EINVAL i 252 It returns 0 on success or the error -EINVAL if a version mismatch is
253 detected. 253 detected.
254 254
255 255
256 AUTOFS_DEV_IOCTL_PROTOVER_CMD and AUTOFS_DEV_I 256 AUTOFS_DEV_IOCTL_PROTOVER_CMD and AUTOFS_DEV_IOCTL_PROTOSUBVER_CMD
257 ---------------------------------------------- 257 ------------------------------------------------------------------
258 258
259 Get the major and minor version of the autofs 259 Get the major and minor version of the autofs protocol version understood
260 by loaded module. This call requires an initia 260 by loaded module. This call requires an initialized struct autofs_dev_ioctl
261 with the ioctlfd field set to a valid autofs m 261 with the ioctlfd field set to a valid autofs mount point descriptor
262 and sets the requested version number in versi 262 and sets the requested version number in version field of struct args_protover
263 or sub_version field of struct args_protosubve 263 or sub_version field of struct args_protosubver. These commands return
264 0 on success or one of the negative error code 264 0 on success or one of the negative error codes if validation fails.
265 265
266 266
267 AUTOFS_DEV_IOCTL_OPENMOUNT and AUTOFS_DEV_IOCT 267 AUTOFS_DEV_IOCTL_OPENMOUNT and AUTOFS_DEV_IOCTL_CLOSEMOUNT
268 ---------------------------------------------- 268 ----------------------------------------------------------
269 269
270 Obtain and release a file descriptor for an au 270 Obtain and release a file descriptor for an autofs managed mount point
271 path. The open call requires an initialized st 271 path. The open call requires an initialized struct autofs_dev_ioctl with
272 the path field set and the size field adjusted 272 the path field set and the size field adjusted appropriately as well
273 as the devid field of struct args_openmount se 273 as the devid field of struct args_openmount set to the device number of
274 the autofs mount. The device number can be obt 274 the autofs mount. The device number can be obtained from the mount options
275 shown in /proc/mounts. The close call requires 275 shown in /proc/mounts. The close call requires an initialized struct
276 autofs_dev_ioct with the ioctlfd field set to 276 autofs_dev_ioct with the ioctlfd field set to the descriptor obtained
277 from the open call. The release of the file de 277 from the open call. The release of the file descriptor can also be done
278 with close(2) so any open descriptors will als 278 with close(2) so any open descriptors will also be closed at process exit.
279 The close call is included in the implemented 279 The close call is included in the implemented operations largely for
280 completeness and to provide for a consistent u 280 completeness and to provide for a consistent user space implementation.
281 281
282 282
283 AUTOFS_DEV_IOCTL_READY_CMD and AUTOFS_DEV_IOCT 283 AUTOFS_DEV_IOCTL_READY_CMD and AUTOFS_DEV_IOCTL_FAIL_CMD
284 ---------------------------------------------- 284 --------------------------------------------------------
285 285
286 Return mount and expire result status from use 286 Return mount and expire result status from user space to the kernel.
287 Both of these calls require an initialized str 287 Both of these calls require an initialized struct autofs_dev_ioctl
288 with the ioctlfd field set to the descriptor o 288 with the ioctlfd field set to the descriptor obtained from the open
289 call and the token field of struct args_ready 289 call and the token field of struct args_ready or struct args_fail set
290 to the wait queue token number, received by us 290 to the wait queue token number, received by user space in the foregoing
291 mount or expire request. The status field of s 291 mount or expire request. The status field of struct args_fail is set to
292 the errno of the operation. It is set to 0 on 292 the errno of the operation. It is set to 0 on success.
293 293
294 294
295 AUTOFS_DEV_IOCTL_SETPIPEFD_CMD 295 AUTOFS_DEV_IOCTL_SETPIPEFD_CMD
296 ------------------------------ 296 ------------------------------
297 297
298 Set the pipe file descriptor used for kernel c 298 Set the pipe file descriptor used for kernel communication to the daemon.
299 Normally this is set at mount time using an op 299 Normally this is set at mount time using an option but when reconnecting
300 to a existing mount we need to use this to tel 300 to a existing mount we need to use this to tell the autofs mount about
301 the new kernel pipe descriptor. In order to pr 301 the new kernel pipe descriptor. In order to protect mounts against
302 incorrectly setting the pipe descriptor we als 302 incorrectly setting the pipe descriptor we also require that the autofs
303 mount be catatonic (see next call). 303 mount be catatonic (see next call).
304 304
305 The call requires an initialized struct autofs 305 The call requires an initialized struct autofs_dev_ioctl with the
306 ioctlfd field set to the descriptor obtained f 306 ioctlfd field set to the descriptor obtained from the open call and
307 the pipefd field of struct args_setpipefd set 307 the pipefd field of struct args_setpipefd set to descriptor of the pipe.
308 On success the call also sets the process grou 308 On success the call also sets the process group id used to identify the
309 controlling process (eg. the owning automount( 309 controlling process (eg. the owning automount(8) daemon) to the process
310 group of the caller. 310 group of the caller.
311 311
312 312
313 AUTOFS_DEV_IOCTL_CATATONIC_CMD 313 AUTOFS_DEV_IOCTL_CATATONIC_CMD
314 ------------------------------ 314 ------------------------------
315 315
316 Make the autofs mount point catatonic. The aut 316 Make the autofs mount point catatonic. The autofs mount will no longer
317 issue mount requests, the kernel communication 317 issue mount requests, the kernel communication pipe descriptor is released
318 and any remaining waits in the queue released. 318 and any remaining waits in the queue released.
319 319
320 The call requires an initialized struct autofs 320 The call requires an initialized struct autofs_dev_ioctl with the
321 ioctlfd field set to the descriptor obtained f 321 ioctlfd field set to the descriptor obtained from the open call.
322 322
323 323
324 AUTOFS_DEV_IOCTL_TIMEOUT_CMD 324 AUTOFS_DEV_IOCTL_TIMEOUT_CMD
325 ---------------------------- 325 ----------------------------
326 326
327 Set the expire timeout for mounts within an au 327 Set the expire timeout for mounts within an autofs mount point.
328 328
329 The call requires an initialized struct autofs 329 The call requires an initialized struct autofs_dev_ioctl with the
330 ioctlfd field set to the descriptor obtained f 330 ioctlfd field set to the descriptor obtained from the open call.
331 331
332 332
333 AUTOFS_DEV_IOCTL_REQUESTER_CMD 333 AUTOFS_DEV_IOCTL_REQUESTER_CMD
334 ------------------------------ 334 ------------------------------
335 335
336 Return the uid and gid of the last process to 336 Return the uid and gid of the last process to successfully trigger a the
337 mount on the given path dentry. 337 mount on the given path dentry.
338 338
339 The call requires an initialized struct autofs 339 The call requires an initialized struct autofs_dev_ioctl with the path
340 field set to the mount point in question and t 340 field set to the mount point in question and the size field adjusted
341 appropriately. Upon return the uid field of st 341 appropriately. Upon return the uid field of struct args_requester contains
342 the uid and gid field the gid. 342 the uid and gid field the gid.
343 343
344 When reconstructing an autofs mount tree with 344 When reconstructing an autofs mount tree with active mounts we need to
345 re-connect to mounts that may have used the or 345 re-connect to mounts that may have used the original process uid and
346 gid (or string variations of them) for mount l 346 gid (or string variations of them) for mount lookups within the map entry.
347 This call provides the ability to obtain this 347 This call provides the ability to obtain this uid and gid so they may be
348 used by user space for the mount map lookups. 348 used by user space for the mount map lookups.
349 349
350 350
351 AUTOFS_DEV_IOCTL_EXPIRE_CMD 351 AUTOFS_DEV_IOCTL_EXPIRE_CMD
352 --------------------------- 352 ---------------------------
353 353
354 Issue an expire request to the kernel for an a 354 Issue an expire request to the kernel for an autofs mount. Typically
355 this ioctl is called until no further expire c 355 this ioctl is called until no further expire candidates are found.
356 356
357 The call requires an initialized struct autofs 357 The call requires an initialized struct autofs_dev_ioctl with the
358 ioctlfd field set to the descriptor obtained f 358 ioctlfd field set to the descriptor obtained from the open call. In
359 addition an immediate expire that's independen 359 addition an immediate expire that's independent of the mount timeout,
360 and a forced expire that's independent of whet 360 and a forced expire that's independent of whether the mount is busy,
361 can be requested by setting the how field of s 361 can be requested by setting the how field of struct args_expire to
362 AUTOFS_EXP_IMMEDIATE or AUTOFS_EXP_FORCED, res 362 AUTOFS_EXP_IMMEDIATE or AUTOFS_EXP_FORCED, respectively . If no
363 expire candidates can be found the ioctl retur 363 expire candidates can be found the ioctl returns -1 with errno set to
364 EAGAIN. 364 EAGAIN.
365 365
366 This call causes the kernel module to check th 366 This call causes the kernel module to check the mount corresponding
367 to the given ioctlfd for mounts that can be ex 367 to the given ioctlfd for mounts that can be expired, issues an expire
368 request back to the daemon and waits for compl 368 request back to the daemon and waits for completion.
369 369
370 AUTOFS_DEV_IOCTL_ASKUMOUNT_CMD 370 AUTOFS_DEV_IOCTL_ASKUMOUNT_CMD
371 ------------------------------ 371 ------------------------------
372 372
373 Checks if an autofs mount point is in use. 373 Checks if an autofs mount point is in use.
374 374
375 The call requires an initialized struct autofs 375 The call requires an initialized struct autofs_dev_ioctl with the
376 ioctlfd field set to the descriptor obtained f 376 ioctlfd field set to the descriptor obtained from the open call and
377 it returns the result in the may_umount field 377 it returns the result in the may_umount field of struct args_askumount,
378 1 for busy and 0 otherwise. 378 1 for busy and 0 otherwise.
379 379
380 380
381 AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD 381 AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD
382 --------------------------------- 382 ---------------------------------
383 383
384 Check if the given path is a mountpoint. 384 Check if the given path is a mountpoint.
385 385
386 The call requires an initialized struct autofs 386 The call requires an initialized struct autofs_dev_ioctl. There are two
387 possible variations. Both use the path field s 387 possible variations. Both use the path field set to the path of the mount
388 point to check and the size field adjusted app 388 point to check and the size field adjusted appropriately. One uses the
389 ioctlfd field to identify a specific mount poi 389 ioctlfd field to identify a specific mount point to check while the other
390 variation uses the path and optionally in.type 390 variation uses the path and optionally in.type field of struct args_ismountpoint
391 set to an autofs mount type. The call returns 391 set to an autofs mount type. The call returns 1 if this is a mount point
392 and sets out.devid field to the device number 392 and sets out.devid field to the device number of the mount and out.magic
393 field to the relevant super block magic number 393 field to the relevant super block magic number (described below) or 0 if
394 it isn't a mountpoint. In both cases the devic 394 it isn't a mountpoint. In both cases the device number (as returned
395 by new_encode_dev()) is returned in out.devid 395 by new_encode_dev()) is returned in out.devid field.
396 396
397 If supplied with a file descriptor we're looki 397 If supplied with a file descriptor we're looking for a specific mount,
398 not necessarily at the top of the mounted stac 398 not necessarily at the top of the mounted stack. In this case the path
399 the descriptor corresponds to is considered a 399 the descriptor corresponds to is considered a mountpoint if it is itself
400 a mountpoint or contains a mount, such as a mu 400 a mountpoint or contains a mount, such as a multi-mount without a root
401 mount. In this case we return 1 if the descrip 401 mount. In this case we return 1 if the descriptor corresponds to a mount
402 point and also returns the super magic of the 402 point and also returns the super magic of the covering mount if there
403 is one or 0 if it isn't a mountpoint. 403 is one or 0 if it isn't a mountpoint.
404 404
405 If a path is supplied (and the ioctlfd field i 405 If a path is supplied (and the ioctlfd field is set to -1) then the path
406 is looked up and is checked to see if it is th 406 is looked up and is checked to see if it is the root of a mount. If a
407 type is also given we are looking for a partic 407 type is also given we are looking for a particular autofs mount and if
408 a match isn't found a fail is returned. If the 408 a match isn't found a fail is returned. If the located path is the
409 root of a mount 1 is returned along with the s 409 root of a mount 1 is returned along with the super magic of the mount
410 or 0 otherwise. 410 or 0 otherwise.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.