| Message ID | 1414079771-2960-1-git-send-email-jack@suse.cz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Jan, On Thu, Oct 23, 2014 at 6:56 PM, Jan Kara <jack@suse.cz> 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@suse.cz> > --- > 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
On Thu, Oct 23, 2014 at 7:16 PM, Trond Myklebust <trond.myklebust@primarydata.com> wrote: > Hi Jan, > > On Thu, Oct 23, 2014 at 6:56 PM, Jan Kara <jack@suse.cz> 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@suse.cz> >> --- >> 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...
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:
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@suse.cz> --- fs/nfs/nfs4proc.c | 2 -- 1 file changed, 2 deletions(-)