From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve French Subject: Re: filesystem client mapping of uid_t/gid_t field in lookup Date: Sun, 15 May 2005 17:37:42 -0500 Message-ID: <4287CF36.2000007@austin.rr.com> References: <42852F4D.4020804@austin.rr.com> <1116052679.13863.38.camel@lade.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from ms-smtp-05.texas.rr.com ([24.93.47.44]:18821 "EHLO ms-smtp-05-eri0.texas.rr.com") by vger.kernel.org with ESMTP id S261287AbVEOWrR (ORCPT ); Sun, 15 May 2005 18:47:17 -0400 To: Trond Myklebust In-Reply-To: <1116052679.13863.38.camel@lade.trondhjem.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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."