Re: filesystem client mapping of uid_t/gid_t field in lookup

[Steve French <smfrench@austin.rr.com>]

Trond Myklebust wrote:

>the uid/gid mapping is done using upcalls to
>a userland daemon on both the client and server side. A cache is used in
>order to avoid too many upcalls. Why would this sort of approach be
>impractical for CIFS?
>
>Cheers,
>  Trond
>
>  
>
It could be done with upcalls which populate a cache of uid mappings, 
but I was worried about avoiding all deadlock cases - not just the 
problem of making sure the user space daemon never dies, and the 
performance implications, but what worried me more was having to do a 
task switch in lookup (and readdir etc.)  to an upcall thread to resolve 
some mappings might result in deadlock if the upcall thread could ever 
get blocked on writeback of inode data that the kernel code has to page 
out.  This also means that the upcall thread has to be aware of which 
smb_uid (smb session) and/or which tree connection (mount to the same 
target UNC name) the mapping is for which is possible but perhaps harder 
to implement than the approach that RFC1813 mentions ie "mapping 
established by the user from a client at mount time."