On Wed, 2012-02-15 at 19:38 +0400, Vitaliy Gusev wrote:
> >From RFC5661, 18.36.3:
>
> ca_maxoperations:
>
> For the backchannel, the server MUST
> NOT change the value the client offers. For the fore channel,
> the server MAY change the requested value.
>
> ca_maxrequests:
>
> For the backchannel, the server MUST NOT change the
> value the client offers. For the fore channel, the server MAY
> change the requested value.
>
> Signed-off-by: Vitaliy Gusev <gusev.vitaliy@xxxxxxxxxxx>
> ---
> fs/nfs/nfs4proc.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
> index 5da5355..233ed26 100644
> --- a/fs/nfs/nfs4proc.c
> +++ b/fs/nfs/nfs4proc.c
> @@ -5199,6 +5199,8 @@ static int nfs4_verify_fore_channel_attrs(struct nfs41_create_session_args *args
> return -EINVAL;
> if (rcvd->max_reqs == 0)
> return -EINVAL;
> + if (rcvd->max_reqs > NFS4_MAX_SLOT_TABLE)
> + rcvd->max_reqs = NFS4_MAX_SLOT_TABLE;
> return 0;
> }
>
> @@ -5214,9 +5216,9 @@ static int nfs4_verify_back_channel_attrs(struct nfs41_create_session_args *args
> if (rcvd->max_resp_sz_cached > sent->max_resp_sz_cached)
> return -EINVAL;
> /* These would render the backchannel useless: */
> - if (rcvd->max_ops == 0)
> + if (rcvd->max_ops != sent->max_ops)
> return -EINVAL;
> - if (rcvd->max_reqs == 0)
> + if (rcvd->max_reqs != sent->max_reqs)
> return -EINVAL;
> return 0;
> }
This looks good, however I'm queueing it up for the 3.4 merge window
rather than adding it as a bugfix for 3.3. The main reason for
postponing is to give us time to check that we don't get bitten by any
servers out there that may have buggy backchannel semantics.
Please let's make sure to test this patch thoroughly at Connectathon
next week!
--
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�����٥
