linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: Olga Kornievskaia <aglo@umich.edu>
Cc: Trond Myklebust <trond.myklebust@hammerspace.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [RFC PATCH] fix krb5p mount not providing large enough buffer in rq_rcvsize
Date: Tue, 10 Mar 2020 15:57:36 -0400	[thread overview]
Message-ID: <FF0659E0-8F04-4005-96D0-5D513881EDFE@oracle.com> (raw)
In-Reply-To: <CAN-5tyHegg96s7mr1YeoPbVd0UA7_cd2GEPYNWx98uUcx-0ARw@mail.gmail.com>

Hi Olga-

> On Mar 10, 2020, at 2:58 PM, Olga Kornievskaia <aglo@umich.edu> wrote:
> 
> Ever since commit 2c94b8eca1a26 "SUNRPC: Use au_rslack when computing
> reply buffer size". It changed how "req->rq_rcvsize" is calculated. It
> used to use au_cslack value which was nice and large and changed it to
> au_rslack value which turns out to be too small.
> 
> Since 5.1, v3 mount with sec=krb5p fails against an Ontap server
> because client's receive buffer it too small.

Can you be more specific? For instance, why is 100 bytes adequate for
Linux servers, but not OnTAP?

Is this explanation for the current value not correct?

  51 /* length of a krb5 verifier (48), plus data added before arguments when
  52  * using integrity (two 4-byte integers): */


> For GSS, au_rslack is calculated from GSS_VERF_SLACK value which is
> currently 100. And it's not enough. Changing it to 104 works and then
> au_rslack is recalculated based on actual received mic.len and not
> just the default buffer size.
> 
> I would like to propose to change it to something a little larger than
> 104, like 120 to give room if some other server might reply with
> something even larger.

Why does it need to be larger than 104?


> Thoughts? Will send an actual patch if no objections to this one.
> 
> diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
> index 24ca861..44ae6bc 100644
> --- a/net/sunrpc/auth_gss/auth_gss.c
> +++ b/net/sunrpc/auth_gss/auth_gss.c
> @@ -50,7 +50,7 @@
> #define GSS_CRED_SLACK         (RPC_MAX_AUTH_SIZE * 2)
> /* length of a krb5 verifier (48), plus data added before arguments when
>  * using integrity (two 4-byte integers): */
> -#define GSS_VERF_SLACK         100
> +#define GSS_VERF_SLACK         120
> 
> static DEFINE_HASHTABLE(gss_auth_hash_table, 4);
> static DEFINE_SPINLOCK(gss_auth_hash_lock);

--
Chuck Lever




  reply	other threads:[~2020-03-10 19:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-10 18:58 [RFC PATCH] fix krb5p mount not providing large enough buffer in rq_rcvsize Olga Kornievskaia
2020-03-10 19:57 ` Chuck Lever [this message]
2020-03-10 21:07   ` Olga Kornievskaia
2020-03-10 23:56     ` Chuck Lever
2020-03-11 14:57       ` Chuck Lever
     [not found]       ` <CAN-5tyHjrNcSc+h62dBiYhNmLxWcR1Pj7fLJOnSfgR6JDZbEAA@mail.gmail.com>
2020-03-12 20:10         ` Chuck Lever
2020-03-20 19:28           ` Olga Kornievskaia
2020-03-20 20:18             ` Chuck Lever

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=FF0659E0-8F04-4005-96D0-5D513881EDFE@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=aglo@umich.edu \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@hammerspace.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).