[pnfs] [PATCH 9/9] pnfs client prevent race in sequence slot

[Trond Myklebust]

On Thu, 2007-09-27 at 11:23 -0700, Iyer, Rahul wrote:
> 
> > -----Original Message-----
> > From: Trond Myklebust [mailto:trond.myklebust at fys.uio.no] 
> > Sent: Thursday, September 27, 2007 11:05 AM
> > To: Benny Halevy
> > Cc: pnfs at linux-nfs.org; andros at umich.edu
> > Subject: Re: [pnfs] [PATCH 9/9] pnfs client prevent race in 
> > sequence slot
> > 
> > On Thu, 2007-09-27 at 17:38 +0200, Benny Halevy wrote:
> > 
> > > I'm afraid there might be more into that. For example, if the 
> > > interrupted rpc was stateid changing you have to process 
> > the reply to 
> > > stay in sync with the server so in general I still think the client 
> > > must process the reply regardless of whether whoever 
> > generated the rpc 
> > > is waiting for it or not.  This means that if an rpc is 
> > interrupted we 
> > > need to return -EINTR upstream and postpone the processing 
> > of the rpc 
> > > reply as if it was an async rpc even if it started as synchronous 
> > > rather than try to second guess the server by probing it. (it could 
> > > have been easier if there was a way to officially try to cancel an 
> > > outstanding rpc...)
> > 
> > That should not be a problem if you guys have followed the 
> > existing prescription of always using asynchronous RPC calls 
> > for stateful operations. Those are always guaranteed to complete.
> >
> 
> This can be a problem because it converts nearly every rpc into an async
> call as there's a sequence op in almost every one of them. 
> -Rahul

Which is why I proposed the workaround for synchronous calls _only_.
Please go back and read my proposal.

Trond