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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux