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 <[email protected]>
---
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
Hi Jan,
On Thu, Oct 23, 2014 at 6:56 PM, Jan Kara <[email protected]> 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 <[email protected]>
> ---
> 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
[email protected]
On Thu, Oct 23, 2014 at 7:16 PM, Trond Myklebust
<[email protected]> wrote:
> Hi Jan,
>
> On Thu, Oct 23, 2014 at 6:56 PM, Jan Kara <[email protected]> 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 <[email protected]>
>> ---
>> 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
[email protected]