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

From: Christoph Hellwig
Date: Fri Apr 29 2005 - 16:41:37 EST

On Fri, Apr 29, 2005 at 04:09:09PM -0500, Steve French wrote:
> > 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.

exporting the uid using the show_options superblock methods sounds like
a much better option.

> 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.

Do you use the same suid wrapper hack for mounts as fuse? Maybe you
should chime in on that thread so we can find a proper solution.

> 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

No. /proc/self/mounts is an ASCII format, so there's no problem with
differemt sizes.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at