From: "J. Bruce Fields" <bfields@redhat.com>
To: Trond Myklebust <trondmy@gmail.com>
Cc: linux-nfs@vger.kernel.org, Neil Brown <neilb@suse.de>,
Chuck Lever <chuck.lever@oracle.com>,
Anna Schumaker <Anna.Schumaker@netapp.com>
Subject: Re: [PATCH 1/3] SUNRPC: The TCP back channel mustn't disappear while requests are outstanding
Date: Wed, 16 Oct 2019 17:38:13 -0400 [thread overview]
Message-ID: <20191016213813.GB1987@pick.fieldses.org> (raw)
In-Reply-To: <20191016141546.32277-1-trond.myklebust@hammerspace.com>
These make sense to me. (But I'll confess I haven't been following the
back and forth with Neil.)
On Wed, Oct 16, 2019 at 10:15:44AM -0400, Trond Myklebust wrote:
> If there are TCP back channel requests either being processed by the
In this patch and the next, is the "either" unnecessary, or was there
some other condition you meant to mention?
--b.
> server threads, then we should hold a reference to the transport
> to ensure it doesn't get freed from underneath us.
>
> Reported-by: Neil Brown <neilb@suse.de>
> Fixes: 2ea24497a1b3 ("SUNRPC: RPC callbacks may be split across several..")
> Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
> ---
> net/sunrpc/backchannel_rqst.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/sunrpc/backchannel_rqst.c b/net/sunrpc/backchannel_rqst.c
> index 339e8c077c2d..7eb251372f94 100644
> --- a/net/sunrpc/backchannel_rqst.c
> +++ b/net/sunrpc/backchannel_rqst.c
> @@ -307,8 +307,8 @@ void xprt_free_bc_rqst(struct rpc_rqst *req)
> */
> dprintk("RPC: Last session removed req=%p\n", req);
> xprt_free_allocation(req);
> - return;
> }
> + xprt_put(xprt);
> }
>
> /*
> @@ -339,7 +339,7 @@ struct rpc_rqst *xprt_lookup_bc_request(struct rpc_xprt *xprt, __be32 xid)
> spin_unlock(&xprt->bc_pa_lock);
> if (new) {
> if (req != new)
> - xprt_free_bc_rqst(new);
> + xprt_free_allocation(new);
> break;
> } else if (req)
> break;
> @@ -368,6 +368,7 @@ void xprt_complete_bc_request(struct rpc_rqst *req, uint32_t copied)
> set_bit(RPC_BC_PA_IN_USE, &req->rq_bc_pa_state);
>
> dprintk("RPC: add callback request to list\n");
> + xprt_get(xprt);
> spin_lock(&bc_serv->sv_cb_lock);
> list_add(&req->rq_bc_list, &bc_serv->sv_cb_list);
> wake_up(&bc_serv->sv_cb_waitq);
> --
> 2.21.0
>
next prev parent reply other threads:[~2019-10-16 21:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-16 14:15 [PATCH 1/3] SUNRPC: The TCP back channel mustn't disappear while requests are outstanding Trond Myklebust
2019-10-16 14:15 ` [PATCH 2/3] SUNRPC: The RDMA " Trond Myklebust
2019-10-16 14:15 ` [PATCH 3/3] SUNRPC: Destroy the back channel when we destroy the host transport Trond Myklebust
2019-10-16 22:08 ` NeilBrown
2019-10-17 13:06 ` Trond Myklebust
2019-10-16 21:38 ` J. Bruce Fields [this message]
2019-10-16 22:24 ` [PATCH 1/3] SUNRPC: The TCP back channel mustn't disappear while requests are outstanding NeilBrown
2019-10-17 12:43 ` Trond Myklebust
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=20191016213813.GB1987@pick.fieldses.org \
--to=bfields@redhat.com \
--cc=Anna.Schumaker@netapp.com \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=trondmy@gmail.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