Re: [PATCH 0/2 v4] nfs: return nfs4 compound header status on op header decoding error

[Benny Halevy <bhalevy@panasas.com>]

On Jul. 17, 2008, 15:09 +0300, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
> On Wed, 2008-07-16 at 16:22 +0300, Benny Halevy wrote:
>> On Jul. 16, 2008, 15:57 +0300, Trond Myklebust <trond.myklebust@fys.uio.no> wrote:
>>> Why do we need to handle OP_ILLEGAL in the first place? This is the
>>> client; it isn't supposed to send illegal operations...
>> Right, but it helps in the development process when dealing with
>> a broken version of the server or the client to pass a less
>> generic error (-EOPNOTSUPP) up the stack rather than -EIO.
> 
> NFS4ERR_OP_ILLEGAL literally means "this operation isn't even listed in
> the 4.0/4.1 RFC". That's out in EYOUUTTERLYINSANECLIENT territory, and
> so the current mapping to EOPNOTSUPP is just wrong.

FWIW, we currently map NFS4ERR_NOTSUPP to -ENOTSUPP and
NFS4ERR_OP_ILLEGAL to -EOPNOTSUPP so one can distinct between
the two cases, even if the latter mapping is wrong.

I'm not sure if there's an available error code that would
describe this NFS4ERR_OP_ILLEGAL perfectly, -EINVAL might
be reasonable but I it's not very distinctive. Maybe we should
add one to include/linux/errno.h?

> 
> NFS4ERR_NOTSUPP is the correct return value if a server doesn't (yet)
> support an operation.
> 
> 
> 

Agreed.

Just that we had a bug in the server that caused us to return
NFS4ERR_OP_ILLEGAL for unimplemented ops rather than NFS4ERR_NOTSUPP.
That's a condition I really want to be aware of while developing the
server.

Benny