From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 8/17] locks: add fl_notify arguments for asynchronous lock return Date: Mon, 9 Apr 2007 19:40:41 +0100 Message-ID: <20070409184041.GA28716@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: akpm@osdl.org, Trond Myklebust , Marc Eshel , linux-fsdevel@vger.kernel.org To: "J. Bruce Fields" Return-path: Received: from pentafluge.infradead.org ([213.146.154.40]:60775 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753371AbXDISku (ORCPT ); Mon, 9 Apr 2007 14:40:50 -0400 Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Apr 05, 2007 at 07:40:58PM -0400, J. Bruce Fields wrote: > From: Marc Eshel - unquoted > > Acquiring a lock on a cluster filesystem may require communication with remote > hosts, and to avoid blocking lockd or nfsd threads during such communication, > we allow the results to be returned asynchronously. > > When a ->lock() call needs to block, the file system will return -EINPROGRESS, > and then later return the results with a call to the routine in the fl_notify > field of the lock_manager_operations struct. > > Note that this is different from the ->lock() call discovering that there is a > conflict which would cause the caller to block; this is still handled in the > same way as before. In fact, we don't currently handle "blocking" locks at > all; those are less urgent, because the filesystem can always just return an > immediate -EAGAIN without denying the lock. > > So this asynchronous interface is only used in the case of a non-blocking lock, > where we must know whether to allow or deny the lock now. > > We're using fl_notify to asynchronously return the result of a lock > request. So we want fl_notify to be able to return a status and, if > appropriate, a conflicting lock. > > This only current caller of fl_notify is in the blocked case, in which case > we don't use these extra arguments. > > We also allow fl_notify to return an error. (Also ignored for now.) I don't really like the overload of fl_notify. What the reason not to use a separate callback?