Re: [PATCH] zero out delegation in the inode after it has been returned

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Mon, 2011-02-28 at 17:01 -0500, Trond Myklebust wrote: 
> On Mon, 2011-02-28 at 16:54 -0500, Jim Rees wrote: 
> > Trond Myklebust wrote:
> > 
> >   nfsi->delegation is released under the appropriate locks well before we
> >   get here. The above line is 100% racy and risks clobbering any new
> >   delegation that has been issued after the delegreturn completed...
> > 
> > I'd have been amazed if I'd gotten it right.  But there really is a problem
> > here, the client does try to use delegations that have been returned, and
> > this patch does solve that problem.  I'm happy to keep after this but would
> > appreciate any suggestions or nudges in the right direction.
> 
> The procedure for returning delegations is supposed to work as follows:
> 
>      1. Remove the nfsi->delegation so that it is no longer visible to
>         new open() requests 
>      2. write back any dirty data to the server 
>      3. Reclaim any locks 
>      4. Reclaim any open stateids (using CLAIM_DELEGATE_CUR) 

Errr.... lock reclaim comes after open reclaim, of course...

The rest is correct.

> 5. delegreturn
> 
> While there may indeed be the odd READ or WRITE that races between 4.
> and 5., so that the server receives the delegation stateid after the
> delegreturn, that shouldn't matter: the server returns an error, and the
> client should retry using the new open stateid.
> 
> What is failing to work correctly here?
>