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. Cheers Trond -- 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
