Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread

[Steve French]

> does and who revied that?  Things like that don't have a business in the
> kernel, and certainly not as ioctl.

Other filesystems such as smbfs had an ioctl that returned the uid of 
the mounter which they used (in the smbfs case in smbumount).  This was 
required by the unmount helper to determine if the unmount would allow a 
user to unmount a particular mount that they mounted.   Unlike in the 
case of mount, for unmount  you can not use the owner uid of the mount 
target to tell who mounted that mount.   I had not received any better 
suggestions as to how to address it.   I had proposed various 
alternatives - exporting in in /proc/mounts e.g.   

As we try to gradually obsolete smbfs, this came up with various users 
(there was even a bugzilla bug opened for adding it) who said that they 
need the ability to unmount their own mounts for network filesystems 
without using /etc/fstab.    Unfortunately for network filesytsems, 
unlike local filesystems, it is impractical to put every possible mount 
target in /etc/fstab since servers get renamed and the universe of 
possible cifs mount targets for a user is large.

There seemed only three alternatives -
1) mimic the smbfs ioctl -   as can be seen from smbfs and smbumount 
source this has portability problems because apparently there is no 
guarantee that uid_t is the same size in kernel and in userspace - smbfs 
actually has two ioctls for different sizes of uid field - this seemed 
like a bad idea
2) export the uid in /proc/mounts - same problem as above
3) call into the kernel to see if current matches the uid of the mounter 
- this has no 16/32/64 bit uid portability issues since the check is 
made in kernel

If there is a better way to achieve these goals I would like to know - I 
had not gotten any feedback on a better way.   Although I am not a fan 
of ioctls, this is as simple as they get and I checked for overlaps in 
the ioctl numbers and the utility checks to make sure it is only invoked 
if the filesystem magic number matches CIFS's magic number and no parms 
are passed or returned so it is quite safe.

Of course I would have preferred that this facility were built into the 
kernel via a syscall so the same approach could be put in umount itself 
instead of in a umount helper.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/