From: "J. Bruce Fields" <bfields@fieldses.org>
To: "William A. (Andy) Adamson" <androsadamson@gmail.com>
Cc: trond.myklebust@netapp.com, bfields@redhat.com,
linux-nfs@vger.kernel.org
Subject: Re: [PATCH_V4 1/9] SUNRPC new transport for the NFSv4.1 shared back channel
Date: Fri, 17 Dec 2010 15:02:23 -0500 [thread overview]
Message-ID: <20101217200223.GE14510@fieldses.org> (raw)
In-Reply-To: <AANLkTinHUSkV4LApqmwk+mU7OS5ro0u859PMtQ39qFPC@mail.gmail.com>
On Fri, Dec 17, 2010 at 02:55:11PM -0500, William A. (Andy) Adamson wrote:
> On Fri, Dec 17, 2010 at 2:33 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > On Fri, Dec 17, 2010 at 02:16:35PM -0500, William A. (Andy) Adamson wrote:
> >> On Fri, Dec 17, 2010 at 2:10 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> >> > On Fri, Dec 17, 2010 at 01:57:50PM -0500, William A. (Andy) Adamson wrote:
> >> >> On Fri, Dec 17, 2010 at 1:54 PM, William A. (Andy) Adamson
> >> >> <androsadamson@gmail.com> wrote:
> >> >> > On Fri, Dec 17, 2010 at 1:40 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> >> >> >> On Fri, Dec 17, 2010 at 01:20:02PM -0500, andros@netapp.com wrote:
> >> >> >>> From: Andy Adamson <andros@netapp.com>
> >> >> >>>
> >> >> >>> Create a new transport for the shared back channel.l Move the current sock
> >> >> >>> create and destroy routines into the new transport ops.
> >> >> >>>
> >> >> >>> Reference the back channel transport across message processing (recv/send).
> >> >> >>>
> >> >> >>> Signed-off-by: Andy Adamson <andros@netapp.com>
> >> >> >>> ---
> >> >> >>> include/linux/sunrpc/svcsock.h | 1 +
> >> >> >>> net/sunrpc/svc.c | 18 +++---
> >> >> >>> net/sunrpc/svcsock.c | 122 +++++++++++++++++++++++++++++++++-------
> >> >> >>> 3 files changed, 112 insertions(+), 29 deletions(-)
> >> >> >>>
> >> >> >>> diff --git a/include/linux/sunrpc/svcsock.h b/include/linux/sunrpc/svcsock.h
> >> >> >>> index 1b353a7..3a45a80 100644
> >> >> >>> --- a/include/linux/sunrpc/svcsock.h
> >> >> >>> +++ b/include/linux/sunrpc/svcsock.h
> >> >> >>> @@ -45,6 +45,7 @@ int svc_sock_names(struct svc_serv *serv, char *buf,
> >> >> >>> int svc_addsock(struct svc_serv *serv, const int fd,
> >> >> >>> char *name_return, const size_t len);
> >> >> >>> void svc_init_xprt_sock(void);
> >> >> >>> +void svc_init_bc_xprt_sock(void);
> >> >> >>> void svc_cleanup_xprt_sock(void);
> >> >> >>> struct svc_xprt *svc_sock_create(struct svc_serv *serv, int prot);
> >> >> >>> void svc_sock_destroy(struct svc_xprt *);
> >> >> >>> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
> >> >> >>> index 6359c42..3520cb3 100644
> >> >> >>> --- a/net/sunrpc/svc.c
> >> >> >>> +++ b/net/sunrpc/svc.c
> >> >> >>> @@ -488,10 +488,6 @@ svc_destroy(struct svc_serv *serv)
> >> >> >>> if (svc_serv_is_pooled(serv))
> >> >> >>> svc_pool_map_put();
> >> >> >>>
> >> >> >>> -#if defined(CONFIG_NFS_V4_1)
> >> >> >>> - svc_sock_destroy(serv->bc_xprt);
> >> >> >>> -#endif /* CONFIG_NFS_V4_1 */
> >> >> >>> -
> >> >> >>> svc_unregister(serv);
> >> >> >>> kfree(serv->sv_pools);
> >> >> >>> kfree(serv);
> >> >> >>> @@ -1264,7 +1260,7 @@ 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;
> >> >> >>> + int ret;
> >> >> >>>
> >> >> >>> /* Build the svc_rqst used by the common processing routine */
> >> >> >>> rqstp->rq_xprt = serv->bc_xprt;
> >> >> >>> @@ -1292,12 +1288,16 @@ 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;
> >> >> >>> + /* Hold a reference to the back channel socket across the call */
> >> >> >>> + svc_xprt_get(serv->bc_xprt);
> >> >> >>
> >> >> >> Either we already have a reference, in which case this is unnecessary,
> >> >> >> or we don't, in which case this is risky.
> >> >> >
> >> >> > This is done so that when svc_xprt_put is called due to an svc_drop
> >> >> > (svc_xprt_release, svc_xprt_put) it is not freed. It's not risky
> >> >> > because AFAICS it's the way the rpc server code is intended to work.
> >> >> > Note that svc_recv calls svc_xprt_get, and svc_send calls svc_xprt_put
> >> >> > for the same reason.
> >> >
> >> > The svc_xprt_put()'s in svc_send/svc_drop balance the get in svc_recv().
> >> > They're needed because on a normal server connections can come and go
> >> > (because clients come and go) during the lifetime of the server.
> >> >
> >> > As I understand it, the client is just creating a new server for each
> >> > backchannel. So the server will never outlive the one connection it
> >> > uses. So you don't need that stuff. It's harmless--just leave it
> >> > alone--but definitely don't try to add additional reference counting
> >> > during the processing.
> >>
> >> If I don't add an svc_xprt_get prior to the svc_process_call, the
> >> svc_xprt_put called in the svc_drop case will free the bc_xprt, which
> >> is not what I want.
> >
> > Looking at the code some more.... Oh, right, because the backchannel
> > doesn't call svc_recv, it calls its own bc_send, which doesn't do a put.
> >
> > Oh, yuch, I see: svc_process_common returns "1" to mean send, "0" to
> > mean drop, and leaves it up to the caller to do the put in the send
> > case. That's confusing.
> >
> > Maybe it would be simpler to have the caller be made responsible for
> > both cases? So:
> >
> > if (svc_process_common(rqstp))
> > send it
> > else
> > drop it
>
> That would work well. I'll send a patch
If you do that you may want your own bc_svc_drop that doesn't bother
with the put?
You'd want to look through svc_xprt_release() to see if any of the rest
of that makes sense in the bc case.
--b.
next prev parent reply other threads:[~2010-12-17 20:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-17 18:20 [PATCH_V4 0/9] NFSv4 callback find client fix Version 4 andros
2010-12-17 18:20 ` [PATCH_V4 1/9] SUNRPC new transport for the NFSv4.1 shared back channel andros
2010-12-17 18:20 ` [PATCH_V4 2/9] NFS use svc_create_xprt for NFSv4.1 callback service andros
2010-12-17 18:20 ` [PATCH_V4 3/9] NFS do not clear minor version at nfs_client free andros
2010-12-17 18:20 ` [PATCH_V4 4/9] NFS implement v4.0 callback_ident andros
2010-12-17 18:20 ` [PATCH_V4 5/9] NFS associate sessionid with callback connection andros
2010-12-17 18:20 ` [PATCH_V4 6/9] NFS reference nfs_client across cb_compound processing andros
2010-12-17 18:20 ` [PATCH_V4 7/9] NFS RPC_AUTH_GSS unsupported on v4.1 back channel andros
2010-12-17 18:20 ` [PATCH_V4 8/9] NFS add session back channel draining andros
2010-12-17 18:20 ` [PATCH_V4 9/9] NFS rename client back channel transport field andros
2010-12-20 14:05 ` [PATCH_V4 6/9] NFS reference nfs_client across cb_compound processing Benny Halevy
2010-12-20 15:44 ` Fred Isaman
2010-12-17 18:40 ` [PATCH_V4 1/9] SUNRPC new transport for the NFSv4.1 shared back channel J. Bruce Fields
2010-12-17 18:54 ` William A. (Andy) Adamson
2010-12-17 18:57 ` William A. (Andy) Adamson
2010-12-17 19:10 ` J. Bruce Fields
2010-12-17 19:16 ` William A. (Andy) Adamson
2010-12-17 19:33 ` J. Bruce Fields
2010-12-17 19:55 ` William A. (Andy) Adamson
2010-12-17 20:02 ` J. Bruce Fields [this message]
2010-12-17 20:11 ` William A. (Andy) Adamson
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=20101217200223.GE14510@fieldses.org \
--to=bfields@fieldses.org \
--cc=androsadamson@gmail.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).