On Jul 22, 2013, at 12:58 PM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx>
wrote:
> On Mon, 2013-07-22 at 12:42 -0400, andros@xxxxxxxxxx wrote:
>> From: Andy Adamson <andros@xxxxxxxxxx>
>>
>> As per RFC 3530 and RFC 5661 Security Considerations
>
> RFC3530-bis, not RFC3530...
>
>> Commit 4edaa308 "NFS: Use "krb5i" to establish NFSv4 state whenever possible"
>> uses the nfs_client cl_rpcclient for all clientid management operations.
>>
>> Signed-off-by: Andy Adamson <andros@xxxxxxxxxx>
>> ---
>> fs/nfs/nfs4proc.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
>> index 7761802..6a30a72 100644
>> --- a/fs/nfs/nfs4proc.c
>> +++ b/fs/nfs/nfs4proc.c
>> @@ -5806,9 +5806,10 @@ static int _nfs4_proc_secinfo(struct inode *dir, const struct qstr *name, struct
>> .rpc_argp = &args,
>> .rpc_resp = &res,
>> };
>> + struct rpc_clnt *clnt = NFS_SERVER(dir)->nfs_client->cl_rpcclient;
>>
>> dprintk("NFS call secinfo %s\n", name->name);
>> - status = nfs4_call_sync(NFS_SERVER(dir)->client, NFS_SERVER(dir), &msg, &args.seq_args, &res.seq_res, 0);
>> + status = nfs4_call_sync(clnt, NFS_SERVER(dir), &msg, &args.seq_args, &res.seq_res, 0);
>> dprintk("NFS reply secinfo: %d\n", status);
>> return status;
>> }
>
> Has this been tested against a variety of server implementations? I know
> what the spec says, but the behaviour we're relying on here is subtly
> changed from what was originally documented in RFC3530.
Not yet. I'll set up some tests.
-->Andy
>
> --
> Trond Myklebust
> Linux NFS client maintainer
>
> NetApp
> Trond.Myklebust@xxxxxxxxxx
> www.netapp.com
--
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
