On Thu, Oct 23, 2014 at 7:16 PM, Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > Hi Jan, > > On Thu, Oct 23, 2014 at 6:56 PM, Jan Kara <jack@xxxxxxx> wrote: >> NFS4ERR_ACCESS has number 13 and thus is matched and returned >> immediately at the beginning of nfs4_map_errors() and there's no point >> in checking it later. >> >> Coverity-id: 733891 >> Signed-off-by: Jan Kara <jack@xxxxxxx> >> --- >> fs/nfs/nfs4proc.c | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c >> index 405bd95c1f58..f45e6ea1b278 100644 >> --- a/fs/nfs/nfs4proc.c >> +++ b/fs/nfs/nfs4proc.c >> @@ -158,8 +158,6 @@ static int nfs4_map_errors(int err) >> return -EACCES; >> case -NFS4ERR_MINOR_VERS_MISMATCH: >> return -EPROTONOSUPPORT; >> - case -NFS4ERR_ACCESS: >> - return -EACCES; >> case -NFS4ERR_FILE_OPEN: >> return -EBUSY; >> default: >> -- >> 1.8.1.4 >> > > Can you guarantee that EACCES will _always_ take the value 13? I don't > think POSIX lists explicit values. > The NFSv4 error codes are sometimes based on old Solaris error code > values, and so often coincide with the Linux values, but I'm not > comfortable yet with the assumption that will always be the case. > D'oh... Never mind. I penetrated the fog of jetlag and now I see what you are saying... -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
