linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: "J. Bruce Fields" <bfields@redhat.com>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: WARN_ON added to rpc_create()
Date: Thu, 18 Aug 2016 17:56:42 -0400	[thread overview]
Message-ID: <20160818215642.GB25052@fieldses.org> (raw)
In-Reply-To: <20F73E14-8CEC-4ED1-8A04-203343839860@oracle.com>

On Wed, Aug 10, 2016 at 02:01:20PM -0400, Chuck Lever wrote:
> Following up.
> 
> 
> > On Aug 3, 2016, at 3:40 PM, Chuck Lever <chuck.lever@oracle.com> wrote:
> > 
> >> 
> >> On Aug 3, 2016, at 1:47 PM, bfields@fieldses.org wrote:
> >> 
> >> On Wed, Aug 03, 2016 at 11:27:47AM -0400, Chuck Lever wrote:
> >>> Hi Bruce-
> >>> 
> >>> I see that commit 39a9beab5acb83176e8b9a4f0778749a09341f1f
> >>> Author:     J. Bruce Fields <bfields@redhat.com>
> >>> AuthorDate: Tue May 17 12:38:21 2016 -0400
> >>> 
> >>>   rpc: share one xps between all backchannels
> >>> 
> >>> has added this piece of code:
> >>> 
> >>> @@ -452,10 +452,20 @@ static struct rpc_clnt *rpc_create_xprt(struct rpc_create_args *args,
> >>>       struct rpc_clnt *clnt = NULL;
> >>>       struct rpc_xprt_switch *xps;
> >>> 
> >>> -       xps = xprt_switch_alloc(xprt, GFP_KERNEL);
> >>> -       if (xps == NULL) {
> >>> -               xprt_put(xprt);
> >>> -               return ERR_PTR(-ENOMEM);
> >>> +       if (args->bc_xprt && args->bc_xprt->xpt_bc_xps) {
> >>> +               WARN_ON(args->protocol != XPRT_TRANSPORT_BC_TCP);
> >>> +               xps = args->bc_xprt->xpt_bc_xps;
> >>> +               xprt_switch_get(xps);
> >>> +       } else {
> >>> 
> >>> 
> >>> the WARN_ON here fires on the server whenever I use NFSv4.1 on RDMA.
> >>> 
> >>> Can you say why it was added? Is there something RPC/RDMA needs to
> >>> do to make the code safe?
> >> 
> >> What is args->protocol in this case?
> >> 
> >> Digging around...  OK, I missed that BC_TCP and BC_RDMA were defined as
> >> OR's of an XPRT_TRANSPORT_BC bit with the identifier of the underlying
> >> transport.  That makes sense.
> >> 
> >> So, I should have just used XPRT_TRANSPORT_BC there--I think all I meant
> >> was "is this a backchannel".
> >> 
> >> Does that fix the problem?
> > 
> > This simple fix eliminates the log noise:
> > 
> > diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
> > index 2808d55..f94caf7 100644
> > --- a/net/sunrpc/clnt.c
> > +++ b/net/sunrpc/clnt.c
> > @@ -520,7 +520,7 @@ struct rpc_clnt *rpc_create(struct rpc_create_args *args)
> >        char servername[48];
> > 
> >        if (args->bc_xprt) {
> > -               WARN_ON(args->protocol != XPRT_TRANSPORT_BC_TCP);
> > +               WARN_ON(!(args->protocol & XPRT_TRANSPORT_BC));
> >                xprt = args->bc_xprt->xpt_bc_xprt;
> >                if (xprt) {
> >                        xprt_get(xprt);
> > 
> > 
> > This code seems to come from:
> > 
> > commit d50039ea5ee63c589b0434baa5ecf6e5075bb6f9
> > Author:     J. Bruce Fields <bfields@redhat.com>
> > AuthorDate: Mon May 16 17:03:42 2016 -0400
> > 
> >    nfsd4/rpc: move backchannel create logic into rpc code
> > 
> > 
> > Where it may have been copied from:
> > 
> > -static struct rpc_clnt *create_backchannel_client(struct rpc_create_args *args)
> > -{
> > -       struct rpc_xprt *xprt;
> > -
> > -       if (args->protocol != XPRT_TRANSPORT_BC_TCP)
> > -               return rpc_create(args);
> > -
> > -       xprt = args->bc_xprt->xpt_bc_xprt;
> > -       if (xprt) {
> > -               xprt_get(xprt);
> > -               return rpc_create_xprt(args, xprt);
> > -       }
> > -
> > -       return rpc_create(args);
> > -}
> > 
> > There's no warning here. In fact, protocol != BC_TCP seems to
> > be expected.
> > 
> > I'm wondering if the warning is needed at all?
> 
> Using NFSv4.1/RDMA against my v4.7 NFS server seems to result
> in a system deadlock in short order on the server. I haven't
> looked further into this because you mentioned you were going
> to have a look at these commits that change the backchannel
> code.

I'm not seeing an obvious bug in those commits, for what it's worth.

--b.

  reply	other threads:[~2016-08-19  1:33 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-03 15:27 WARN_ON added to rpc_create() Chuck Lever
2016-08-03 17:47 ` J. Bruce Fields
2016-08-03 19:40   ` Chuck Lever
2016-08-10 18:01     ` Chuck Lever
2016-08-18 21:56       ` J. Bruce Fields [this message]
2016-08-18 21:59         ` Chuck Lever
2016-08-19 14:51           ` J. Bruce Fields
2016-08-18 21:56     ` J. Bruce Fields
2016-08-18 22:11       ` Chuck Lever
2016-08-19 14:50         ` J. Bruce Fields
2016-08-19 15:06           ` Chuck Lever
2016-08-19 15:19             ` Chuck Lever
2016-08-19 15:47             ` J. Bruce Fields
2016-08-19 15:51               ` Chuck Lever
2016-08-19 15:55                 ` 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=20160818215642.GB25052@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=bfields@redhat.com \
    --cc=chuck.lever@oracle.com \
    --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;
as well as URLs for NNTP newsgroup(s).