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

[Steve French]

Christoph Hellwig wrote:

> should export it in /proc/<pid>/mounts, which is
> an ASCII interface and any half-sane parser does not depend on the width
> of the field in the kernel.
>
> Can we please get rid of the broken ioctl now so it doesn't become part
> of the ABI and you'll add the trivial output to /proc/<pid>/mounts?
>
>
>  
OK - why don't we just add this (ie the ioctl removal) to the patch

[PATCH] unprivileged mount/umount

of Miklos et al, since that removes the need to modify showmounts (and 
avoids any name collision/confusion
with the existing meaning of the mount option "uid" ie as the default 
uid to use for files on the system when
mounting to servers which can not return inode owners as uids).

On another topic relating to ioctls, various people have suggested 
adding an ioctl to add a table to optionally map file owner (uid / gid 
mapping tables) on remote filesystems. Although this is easy enough to 
do for the case of CIFS, this seems like a function (loading the table) 
that could be done via /proc or perhaps even sysfs. Is there are 
precedent for doing this on Linux? Googling I see various examples where 
NFS client on other platforms (not Linux) have done something vaguely 
similar. NFSv4 uses an upcall for this (although they are mapping 
slightly differently since they now receive a fully qualified username 
and have to map this to a loca uid, rather than getting a remote uid to 
local uid as earlier nfs did). The general issue is that when mounting 
to multiple Unix/Linux servers (especially in different domains), unlike 
in Windows (or perhaps MacOS), similar users are defined with different 
uids, and there are cases where mapping uids/gids or ranges of uids/gids
from that returned from the server would be helpful. The mapping table 
would have to hang off the tree connection or the SMB session for the 
case of CIFS but I would rather not use an ioctl to load it, yet if the 
table ever got big, I would prefer not to use /proc either. Is there a 
recommended approach.
-
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/