From: Trond Myklebust <trondmy@kernel.org>
To: tmenninger@purestorage.com, anna@kernel.org
Cc: cel@kernel.org, ebadger@everpuredata.com,
jcurley@everpuredata.com, jlayton@kernel.org,
linux-kernel@vger.kernel.org, linux-nfs@vger.kernel.org,
netdev@vger.kernel.org, slingappa@everpuredata.com,
Tim Menninger <tmenninger@everpuredata.com>
Subject: Re: [PATCH v2 1/2] SUNRPC: add request-scoped disconnects when cancelling tasks
Date: Wed, 04 Nov 2026 22:14:47 -0500 [thread overview]
Message-ID: <681354cdb85b67410793908d9aa4ee37a06408d2.camel@kernel.org> (raw)
In-Reply-To: <20261105020249.2607367-2-tmenninger@purestorage.com>
On Thu, 2026-11-05 at 02:02 +0000, tmenninger@purestorage.com wrote:
> From: Tim Menninger <tmenninger@everpuredata.com>
>
> rpc_cancel_tasks() allows callers to cancel a selected set of RPC
> tasks,
> but callers that also need to tear down the connection currently have
> to
> disconnect at the rpc_clnt level.
>
> That is broader than necessary for clients with multiple transports.
> A
> cancelled request is associated with a specific rpc_xprt and records
> the
> connection generation on which it was transmitted in
> rq_connect_cookie.
>
> Add rpc_cancel_tasks_and_disconnect() to cancel matching tasks and
> mark
> matching requests that remain on the transport transmit or receive
> queues
> for conditional transport disconnect when the request is released.
>
> Store the disconnect indication in struct rpc_rqst rather than struct
> rpc_task. An RPC task can release one request and later acquire
> another,
> so task-scoped state could otherwise be consumed by a successor
> request
> and disconnect the wrong transport generation.
>
> After cancelling matching tasks, walk the client's transports and
> mark
> matching requests belonging to that client that remain on the
> transmit
> or receive queues. An rpc_xprt may be shared by multiple rpc_clnt
> instances, so requests belonging to other clients are left untouched.
>
> When a marked request is released, use xprt_conditional_disconnect()
> with
> its saved rq_connect_cookie. This disconnects the transport only if
> it is
> still using the same connection generation on which the request was
> sent,
> and leaves a replacement connection untouched.
>
> Requests that were never transmitted do not require a disconnect.
>
I'm all for optimising where it makes sense, however this is adding
another spinlock protected section in xprt_release() for something that
is clearly a rare corner case.
So how about something like the following change instead?
8<---------------------------------------------------------------
diff --git a/fs/nfs/flexfilelayout/flexfilelayout.c b/fs/nfs/flexfilelayout/flexfilelayout.c
index 7fe8b91fa47c..42b0b04de659 100644
--- a/fs/nfs/flexfilelayout/flexfilelayout.c
+++ b/fs/nfs/flexfilelayout/flexfilelayout.c
@@ -2459,6 +2459,12 @@ static bool ff_layout_match_io(const struct rpc_task *task, const void *data)
return false;
}
+static bool ff_layout_match_untransmitted_io(const struct rpc_task *task,
+ const void *data)
+{
+ return !RPC_WAS_SENT(task) && ff_layout_match_io(task, data);
+}
+
static void ff_layout_cancel_io(struct pnfs_layout_segment *lseg)
{
struct nfs4_ff_layout_segment *flseg = FF_LAYOUT_LSEG(lseg);
@@ -2484,6 +2490,9 @@ static void ff_layout_cancel_io(struct pnfs_layout_segment *lseg)
clnt = ds_clp->cl_rpcclient;
if (!clnt)
continue;
+ rpc_cancel_tasks(clnt, -ECANCELED,
+ ff_layout_match_untransmitted_io,
+ lseg);
if (!rpc_cancel_tasks(clnt, -ECANCELED,
ff_layout_match_io, lseg))
continue;
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com
next prev parent reply other threads:[~2026-11-05 3:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 2:02 [PATCH v2 0/2] SUNRPC/NFS: limit transport disconnects when cancelling flexfiles I/O tmenninger
2026-11-05 2:02 ` [PATCH v2 1/2] SUNRPC: add request-scoped disconnects when cancelling tasks tmenninger
2026-11-05 3:14 ` Trond Myklebust [this message]
2026-11-05 3:20 ` Trond Myklebust
2026-11-05 2:02 ` [PATCH v2 2/2] NFSv4/flexfiles: limit transport disconnects when cancelling I/O tmenninger
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=681354cdb85b67410793908d9aa4ee37a06408d2.camel@kernel.org \
--to=trondmy@kernel.org \
--cc=anna@kernel.org \
--cc=cel@kernel.org \
--cc=ebadger@everpuredata.com \
--cc=jcurley@everpuredata.com \
--cc=jlayton@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=slingappa@everpuredata.com \
--cc=tmenninger@everpuredata.com \
--cc=tmenninger@purestorage.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
all inboxes | Powered by JetHome®