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.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
