Re: Patch for mapping EILSEQ into NFSERR_INVAL

[Dr Fields James Bruce <bfields@fieldses.org>]

On Wed, Dec 04, 2013 at 04:22:48PM -0500, Trond Myklebust wrote:
> 
> On Dec 4, 2013, at 16:03, Dr Fields James Bruce <bfields@fieldses.org> wrote:
> 
> > On Wed, Dec 04, 2013 at 10:44:45PM +0200, Antti Tönkyrä wrote:
> > 
> >>>> http://daedalus.pingtimeout.net/dbg/eilseq_ioerr.pcap
> > 
> > And I see something I'd overlooked before: the client is sending the
> > later opens with the same open owner and sequence id.  But NFS4ERR_IO is
> > a seqid-mutating error.  So now I think this probably *is* a client
> > bug....
> 
> Umm… Yes and no. The client should be able to recover when it discovers that the seqid is out of sync.
>
> That said, I see that we do
> 
>        status = decode_op_hdr(xdr, OP_OPEN);
>         if (status != -EIO)
>                 nfs_increment_open_seqid(status, res->seqid);
> 
> and since NFS4ERR_IO == EIO, that means we skip the seqid update when you send us NFS4ERR_IO.

Oh, OK.  Maybe decode_op_hdr could use -NFS4ERR_BADXDR for the two
decoding errors it catches and eliminate the need for this special -EIO
case?

I think NFS4ERR_IO is a legal error for these operations.  (Even if the
server should have returned something else in this case.)

--b.