Linux NFS development
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@kernel.org>
To: Chuck Lever <cel@kernel.org>, linux-nfs@vger.kernel.org
Subject: Re: [PATCH v1 01/27] SUNRPC: Clean up svcauth_gss_release()
Date: Tue, 10 Jan 2023 09:01:19 -0500	[thread overview]
Message-ID: <fd1a0ac033f46229fadf03613d0664c2e817b066.camel@kernel.org> (raw)
In-Reply-To: <167319531054.7490.10405247832294580026.stgit@bazille.1015granger.net>

On Sun, 2023-01-08 at 11:28 -0500, Chuck Lever wrote:
> From: Chuck Lever <chuck.lever@oracle.com>
> 
> Now that upper layers use an xdr_stream to track the construction
> of each RPC Reply message, resbuf->len is kept up-to-date
> automatically. There's no need to recompute it in svc_gss_release().
> 
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
>  net/sunrpc/auth_gss/svcauth_gss.c |   30 ++++++++++++++++--------------
>  1 file changed, 16 insertions(+), 14 deletions(-)
> 
> diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcauth_gss.c
> index 2e603358fae1..4a576ed7aa32 100644
> --- a/net/sunrpc/auth_gss/svcauth_gss.c
> +++ b/net/sunrpc/auth_gss/svcauth_gss.c
> @@ -969,12 +969,6 @@ svcauth_gss_unwrap_integ(struct svc_rqst *rqstp, u32 seq, struct gss_ctx *ctx)
>  	return -EINVAL;
>  }
>  
> -static inline int
> -total_buf_len(struct xdr_buf *buf)
> -{
> -	return buf->head[0].iov_len + buf->page_len + buf->tail[0].iov_len;
> -}
> -
>  /*
>   * RFC 2203, Section 5.3.2.3
>   *
> @@ -1882,14 +1876,25 @@ svcauth_gss_wrap_resp_priv(struct svc_rqst *rqstp)
>  	return 0;
>  }
>  
> +/**
> + * svcauth_gss_release - Wrap payload and release resources
> + * @rqstp: RPC transaction context
> + *
> + * Return values:
> + *    %0: the Reply is ready to be sent
> + *    %-ENOMEM: failed to allocate memory
> + *    %-EINVAL: encoding error
> + *
> + * XXX: These return values do not match the return values documented
> + *      for the auth_ops ->release method in linux/sunrpc/svcauth.h.

As an aside...

It looks like the only place ->release is called is in svc_authorise,
and its callers either ignore the return, or just test whether it
succeeded (returned 0). If it fails then it looks like the xprt is
closed.

The actual return code doesn't matter at all. We could make ->release a
bool return to make that clear.

That's not directly related to this set though.


>  static int
>  svcauth_gss_release(struct svc_rqst *rqstp)
>  {
> -	struct gss_svc_data *gsd = (struct gss_svc_data *)rqstp->rq_auth_data;
> -	struct rpc_gss_wire_cred *gc;
> -	struct xdr_buf *resbuf = &rqstp->rq_res;
> -	int stat = -EINVAL;
>  	struct sunrpc_net *sn = net_generic(SVC_NET(rqstp), sunrpc_net_id);
> +	struct gss_svc_data *gsd = rqstp->rq_auth_data;
> +	struct rpc_gss_wire_cred *gc;
> +	int stat;
>  
>  	if (!gsd)
>  		goto out;
> @@ -1899,10 +1904,7 @@ svcauth_gss_release(struct svc_rqst *rqstp)
>  	/* Release can be called twice, but we only wrap once. */
>  	if (gsd->verf_start == NULL)
>  		goto out;
> -	/* normally not set till svc_send, but we need it here: */
> -	/* XXX: what for?  Do we mess it up the moment we call svc_putu32
> -	 * or whatever? */
> -	resbuf->len = total_buf_len(resbuf);
> +
>  	switch (gc->gc_svc) {
>  	case RPC_GSS_SVC_NONE:
>  		break;
> 
> 

The patch itself looks fine.

Reviewed-by: Jeff Layton <jlayton@kernel.org>

  reply	other threads:[~2023-01-10 14:01 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-08 16:28 [PATCH v1 00/27] Server-side RPC reply header parsing overhaul Chuck Lever
2023-01-08 16:28 ` [PATCH v1 01/27] SUNRPC: Clean up svcauth_gss_release() Chuck Lever
2023-01-10 14:01   ` Jeff Layton [this message]
2023-01-08 16:28 ` [PATCH v1 02/27] SUNRPC: Rename automatic variables in svcauth_gss_wrap_resp_integ() Chuck Lever
2023-01-08 16:28 ` [PATCH v1 03/27] SUNRPC: Record gss_get_mic() errors in svcauth_gss_wrap_integ() Chuck Lever
2023-01-08 16:28 ` [PATCH v1 04/27] SUNRPC: Replace checksum construction " Chuck Lever
2023-01-08 16:28 ` [PATCH v1 05/27] SUNRPC: Convert svcauth_gss_wrap_integ() to use xdr_stream() Chuck Lever
2023-01-08 16:29 ` [PATCH v1 06/27] SUNRPC: Rename automatic variables in svcauth_gss_wrap_resp_priv() Chuck Lever
2023-01-08 16:29 ` [PATCH v1 07/27] SUNRPC: Record gss_wrap() errors in svcauth_gss_wrap_priv() Chuck Lever
2023-01-08 16:29 ` [PATCH v1 08/27] SUNRPC: Add @head and @tail variables " Chuck Lever
2023-01-08 16:29 ` [PATCH v1 09/27] SUNRPC: Convert svcauth_gss_wrap_priv() to use xdr_stream() Chuck Lever
2023-01-08 16:29 ` [PATCH v1 10/27] SUNRPC: Check rq_auth_stat when preparing to wrap a response Chuck Lever
2023-01-08 16:29 ` [PATCH v1 11/27] SUNRPC: Remove the rpc_stat variable in svc_process_common() Chuck Lever
2023-01-08 16:29 ` [PATCH v1 12/27] SUNRPC: Add XDR encoding helper for opaque_auth Chuck Lever
2023-01-08 16:29 ` [PATCH v1 13/27] SUNRPC: Push svcxdr_init_encode() into svc_process_common() Chuck Lever
2023-01-08 16:29 ` [PATCH v1 14/27] SUNRPC: Move svcxdr_init_encode() into ->accept methods Chuck Lever
2023-01-08 16:29 ` [PATCH v1 15/27] SUNRPC: Use xdr_stream to encode Reply verifier in svcauth_null_accept() Chuck Lever
2023-01-08 16:30 ` [PATCH v1 16/27] SUNRPC: Use xdr_stream to encode Reply verifier in svcauth_unix_accept() Chuck Lever
2023-01-08 16:30 ` [PATCH v1 17/27] SUNRPC: Use xdr_stream to encode Reply verifier in svcauth_tls_accept() Chuck Lever
2023-01-08 16:30 ` [PATCH v1 18/27] SUNRPC: Convert unwrap data paths to use xdr_stream for replies Chuck Lever
2023-01-08 16:30 ` [PATCH v1 19/27] SUNRPC: Use xdr_stream to encode replies in server-side GSS upcall helpers Chuck Lever
2023-01-08 16:30 ` [PATCH v1 20/27] SUNRPC: Use xdr_stream for encoding GSS reply verifiers Chuck Lever
2023-01-08 16:30 ` [PATCH v1 21/27] SUNRPC: Hoist init_encode out of svc_authenticate() Chuck Lever
2023-01-08 16:30 ` [PATCH v1 22/27] SUNRPC: Convert RPC Reply header encoding to use xdr_stream Chuck Lever
2023-01-08 16:30 ` [PATCH v1 23/27] SUNRPC: Final clean-up of svc_process_common() Chuck Lever
2023-01-08 16:30 ` [PATCH v1 24/27] SUNRPC: Remove no-longer-used helper functions Chuck Lever
2023-01-08 16:30 ` [PATCH v1 25/27] SUNRPC: Refactor RPC server dispatch method Chuck Lever
2023-01-08 16:31 ` [PATCH v1 26/27] SUNRPC: Set rq_accept_statp inside ->accept methods Chuck Lever
2023-05-02 11:01   ` Jiri Slaby
2023-05-02 14:14     ` Chuck Lever III
2023-05-02 21:29       ` NeilBrown
2023-05-16 19:23       ` Jeff Layton
2023-05-16 19:25         ` Chuck Lever III
2023-05-16 21:25           ` Jeff Layton
2023-05-16 21:27             ` Chuck Lever III
2023-05-16 22:28               ` Jeff Layton
2023-01-08 16:31 ` [PATCH v1 27/27] SUNRPC: Go back to using gsd->body_start Chuck Lever
2023-01-10 14:53 ` [PATCH v1 00/27] Server-side RPC reply header parsing overhaul Jeff Layton
2023-01-10 15:16   ` Chuck Lever III

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=fd1a0ac033f46229fadf03613d0664c2e817b066.camel@kernel.org \
    --to=jlayton@kernel.org \
    --cc=cel@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    /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