All of lore.kernel.org
 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:11 -0400	[thread overview]
Message-ID: <20160818215611.GA25052@fieldses.org> (raw)
In-Reply-To: <5E7D6A55-B7F3-411D-A74B-E8BCE04BCF02@oracle.com>

On Wed, Aug 03, 2016 at 03:40:11PM -0400, Chuck Lever 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.

The protocol should be BC_TCP (OK, actually just BC) if and only if
bc_xprt is set.

(The BC_TCP case is the 4.1+ case, the other is the 4.0 case.  In the
4.1+ case, the new client uses an existing (client-initiated)
connection, in the 4.0 case, the new client must also have a new
connection.

In the 4.0 case we'll always create a new xprt, in the 4.1 case we might
or might not--depends on whether that particular connection has been
used for a backchannel previously.)

--b.

  parent reply	other threads:[~2016-08-19  1:53 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
2016-08-18 21:59         ` Chuck Lever
2016-08-19 14:51           ` J. Bruce Fields
2016-08-18 21:56     ` J. Bruce Fields [this message]
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=20160818215611.GA25052@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.