Re: [PATCH 8/17] locks: add fl_notify arguments for asynchronous lock return

[Christoph Hellwig <hch@infradead.org>]

On Thu, Apr 05, 2007 at 07:40:58PM -0400, J. Bruce Fields wrote:
> From: Marc Eshel <eshel@almaden.ibm.com> - 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?