linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: andros@netapp.com
Cc: trond.myklebust@netapp.com, bfields@redhat.com,
	linux-nfs@vger.kernel.org
Subject: Re: [PATCH_V5 01/11] SUNRPC move svc_drop to caller of svc_process_common
Date: Tue, 21 Dec 2010 13:23:05 -0500	[thread overview]
Message-ID: <20101221182305.GA19349@fieldses.org> (raw)
In-Reply-To: <1292879088-7821-2-git-send-email-andros@netapp.com>

On Mon, Dec 20, 2010 at 04:04:38PM -0500, andros@netapp.com wrote:
> From: Andy Adamson <andros@netapp.com>
> 
> The NFSv4.1 shared back channel does not need to call svc_drop because the
> callback service never outlives the single connection it services, and it
> reuses it's buffers and keeps the trasport.

Looks better....

> Signed-off-by: Andy Adamson <andros@netapp.com>
> ---
>  net/sunrpc/svc.c |   30 ++++++++++++++++--------------
>  1 files changed, 16 insertions(+), 14 deletions(-)
> 
> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
> index 6359c42..606d182 100644
> --- a/net/sunrpc/svc.c
> +++ b/net/sunrpc/svc.c
> @@ -1147,7 +1147,6 @@ svc_process_common(struct svc_rqst *rqstp, struct kvec *argv, struct kvec *resv)
>   dropit:
>  	svc_authorise(rqstp);	/* doesn't hurt to call this twice */
>  	dprintk("svc: svc_process dropit\n");
> -	svc_drop(rqstp);
>  	return 0;
>  
>  err_short_len:
> @@ -1218,7 +1217,6 @@ svc_process(struct svc_rqst *rqstp)
>  	struct kvec		*resv = &rqstp->rq_res.head[0];
>  	struct svc_serv		*serv = rqstp->rq_server;
>  	u32			dir;
> -	int			error;
>  
>  	/*
>  	 * Setup response xdr_buf.
> @@ -1246,11 +1244,13 @@ svc_process(struct svc_rqst *rqstp)
>  		return 0;
>  	}
>  
> -	error = svc_process_common(rqstp, argv, resv);
> -	if (error <= 0)

Oh, and that was pretty ugly, seeing as svc_process_common never
returned <0.  Thanks for cleaning that up.

> -		return error;
> -
> -	return svc_send(rqstp);
> +	/* Returns 1 for send, 0 for drop */
> +	if (svc_process_common(rqstp, argv, resv))
> +		return svc_send(rqstp);
> +	else {
> +		svc_drop(rqstp);
> +		return 0;
> +	}
>  }
>  
>  #if defined(CONFIG_NFS_V4_1)
> @@ -1264,7 +1264,6 @@ bc_svc_process(struct svc_serv *serv, struct rpc_rqst *req,
>  {
>  	struct kvec	*argv = &rqstp->rq_arg.head[0];
>  	struct kvec	*resv = &rqstp->rq_res.head[0];
> -	int 		error;
>  
>  	/* Build the svc_rqst used by the common processing routine */
>  	rqstp->rq_xprt = serv->bc_xprt;
> @@ -1292,12 +1291,15 @@ bc_svc_process(struct svc_serv *serv, struct rpc_rqst *req,
>  	svc_getu32(argv);	/* XID */
>  	svc_getnl(argv);	/* CALLDIR */
>  
> -	error = svc_process_common(rqstp, argv, resv);
> -	if (error <= 0)
> -		return error;
> -
> -	memcpy(&req->rq_snd_buf, &rqstp->rq_res, sizeof(req->rq_snd_buf));
> -	return bc_send(req);
> +	/* Returns 1 for send, 0 for drop */
> +	if (svc_process_common(rqstp, argv, resv)) {
> +		memcpy(&req->rq_snd_buf, &rqstp->rq_res,
> +						sizeof(req->rq_snd_buf));
> +		return bc_send(req);
> +	} else {
> +		/* Nothing to do to drop request */
> +		return 0;

The one thing that bothers me is the svc_reserve stuff.  Which you have
no use for, I guess.  But svc_reserve_auth() is called from
svc_process_common(); I wonder if that can get us into trouble?  I'll
look a little closer.

--b.

> +	}
>  }
>  EXPORT_SYMBOL(bc_svc_process);
>  #endif /* CONFIG_NFS_V4_1 */

  parent reply	other threads:[~2010-12-21 18:23 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-20 21:04 [PATCH_V5 0/11] NFSv4 callback find client fix Version 5 andros
2010-12-20 21:04 ` [PATCH_V5 01/11] SUNRPC move svc_drop to caller of svc_process_common andros
2010-12-20 21:04   ` [PATCH_V5 02/11] SUNRPC fix bc_send print andros
2010-12-20 21:04     ` [PATCH_V5 03/11] SUNRPC new transport for the NFSv4.1 shared back channel andros
2010-12-20 21:04       ` [PATCH_V5 04/11] NFS use svc_create_xprt for NFSv4.1 callback service andros
2010-12-20 21:04         ` [PATCH_V5 05/11] NFS do not clear minor version at nfs_client free andros
2010-12-20 21:04           ` [PATCH_V5 06/11] NFS implement v4.0 callback_ident andros
2010-12-20 21:04             ` [PATCH_V5 07/11] NFS associate sessionid with callback connection andros
2010-12-20 21:04               ` [PATCH_V5 08/11] NFS reference nfs_client across cb_compound processing andros
2010-12-20 21:04                 ` [PATCH_V5 09/11] NFS RPC_AUTH_GSS unsupported on v4.1 back channel andros
2010-12-20 21:04                   ` [PATCH_V5 10/11] NFS add session back channel draining andros
2010-12-20 21:04                     ` [PATCH_V5 11/11] NFS rename client back channel transport field andros
2010-12-22 22:27                   ` [PATCH_V5 09/11] NFS RPC_AUTH_GSS unsupported on v4.1 back channel J. Bruce Fields
2010-12-22 22:26                 ` [PATCH_V5 08/11] NFS reference nfs_client across cb_compound processing J. Bruce Fields
2010-12-22 22:24       ` [PATCH_V5 03/11] SUNRPC new transport for the NFSv4.1 shared back channel J. Bruce Fields
2010-12-24 17:43         ` J. Bruce Fields
2010-12-21 18:23   ` J. Bruce Fields [this message]
2010-12-22 22:00     ` [PATCH_V5 01/11] SUNRPC move svc_drop to caller of svc_process_common Andy Adamson
2010-12-22 22:18       ` J. Bruce Fields
2010-12-24  3:43     ` Labiaga, Ricardo
2010-12-24 17:01       ` J. Bruce Fields

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=20101221182305.GA19349@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=andros@netapp.com \
    --cc=bfields@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@netapp.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).