All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chuck Lever <cel@kernel.org>
To: NeilBrown <neil@brown.name>, Jeff Layton <jlayton@kernel.org>,
	Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo <dai.ngo@oracle.com>, Tom Talpey <tom@talpey.com>
Cc: <linux-nfs@vger.kernel.org>
Subject: [PATCH v1 7/7] sunrpc: assign RQ_LOCAL from the transport on every receive
Date: Sun,  4 Oct 2026 15:40:29 -0400	[thread overview]
Message-ID: <20261004194029.10714-8-cel@kernel.org> (raw)
In-Reply-To: <20261004194029.10714-1-cel@kernel.org>

Only svc_tcp_recvfrom() assigns RQ_LOCAL. A request that arrives
over UDP or RDMA, or that svc_deferred_recv() replays, leaves the
svc_rqst with the value from the last TCP request its thread
received. When RQ_LOCAL is set, nfsd_vfs_write() sets
PF_LOCAL_THROTTLE, and dirty throttling considers only the backing
device being written. A stale RQ_LOCAL relaxes throttling that way
for a WRITE from a remote client. A stale clear bit withholds the
relaxation from a replayed WRITE that did arrive over loopback, and
NFSD can lock up behind the NFS client's dirty pages.

Assign RQ_LOCAL from XPT_LOCAL in svc_handle_xprt() before the
request is received. A deferred request is replayed on the
transport it arrived on, so struct svc_deferred_req needs no copy
of the flag. Only svc_tcp_accept() sets XPT_LOCAL. After the
change, RQ_LOCAL is clear for every UDP and RDMA request, including
one that arrives over loopback.

Fixes: ef11ce24875a ("SUNRPC: track whether a request is coming from a loop-back interface.")
Signed-off-by: Chuck Lever <cel@kernel.org>
---
 net/sunrpc/svc_xprt.c | 2 ++
 net/sunrpc/svcsock.c  | 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/sunrpc/svc_xprt.c b/net/sunrpc/svc_xprt.c
index 031cbac2a612..acb6e58dc522 100644
--- a/net/sunrpc/svc_xprt.c
+++ b/net/sunrpc/svc_xprt.c
@@ -884,6 +884,8 @@ static void svc_handle_xprt(struct svc_rqst *rqstp, struct svc_xprt *xprt)
 		svc_xprt_received(xprt);
 	} else if (svc_xprt_reserve_slot(rqstp, xprt)) {
 		/* XPT_DATA|XPT_DEFERRED case: */
+		assign_bit(RQ_LOCAL, &rqstp->rq_flags,
+			   test_bit(XPT_LOCAL, &xprt->xpt_flags));
 		rqstp->rq_deferred = svc_deferred_dequeue(xprt);
 		if (rqstp->rq_deferred)
 			len = svc_deferred_recv(rqstp);
diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
index 1814e49c671d..b226bb3cd287 100644
--- a/net/sunrpc/svcsock.c
+++ b/net/sunrpc/svcsock.c
@@ -1287,8 +1287,6 @@ static int svc_tcp_recvfrom(struct svc_rqst *rqstp)
 
 	rqstp->rq_xprt_ctxt   = NULL;
 	rqstp->rq_prot	      = IPPROTO_TCP;
-	assign_bit(RQ_LOCAL, &rqstp->rq_flags,
-		   test_bit(XPT_LOCAL, &svsk->sk_xprt.xpt_flags));
 
 	/* Completing one message stops ->read_sock with whatever
 	 * follows still queued, and no path from here re-arms XPT_DATA.
-- 
2.55.0


      parent reply	other threads:[~2026-10-04 19:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-04 19:40 [PATCH v1 0/7] NFSD short subjects Chuck Lever
2026-10-04 19:40 ` [PATCH v1 1/7] nfsd: use direct I/O only for the last operation in a COMPOUND Chuck Lever
2026-10-04 19:40 ` [PATCH v1 2/7] nfsd: account for page_base when advancing rq_next_page Chuck Lever
2026-10-04 19:40 ` [PATCH v1 3/7] nfsd: locate the READ sink page from the reply buffer Chuck Lever
2026-10-04 19:40 ` [PATCH v1 4/7] nfsd: keep spliced pages below rq_next_page when a READ fails Chuck Lever
2026-10-04 19:40 ` [PATCH v1 5/7] nfsd: remove unreachable cancel of the layout fence work Chuck Lever
2026-10-04 19:40 ` [PATCH v1 6/7] sunrpc: preserve rq_daddrlen across request deferral Chuck Lever
2026-10-04 19:40 ` Chuck Lever [this message]

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=20261004194029.10714-8-cel@kernel.org \
    --to=cel@kernel.org \
    --cc=dai.ngo@oracle.com \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=tom@talpey.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 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.