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.
next prev 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 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).