Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread
From: Steve French (smfrench_at_austin.rr.com)
Date: 04/29/05
- Previous message: Steve French: "Re: which ioctls matter across filesystems"
- Next in thread: Christoph Hellwig: "Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread"
- Reply: Christoph Hellwig: "Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread"
- Maybe reply: Bodo Eggert
: "Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread" - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 29 Apr 2005 16:09:09 -0500 To: linux-kernel@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- Previous message: Steve French: "Re: which ioctls matter across filesystems"
- Next in thread: Christoph Hellwig: "Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread"
- Reply: Christoph Hellwig: "Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread"
- Maybe reply: Bodo Eggert
: "Re: [PATCH] cifs: handle termination of cifs oplockd kernel thread" - Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
