diff options
| author | Chuck Lever <chuck.lever@oracle.com> | 2019-01-09 10:04:57 -0500 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2019-01-31 08:15:35 +0100 |
| commit | 237563f7d004f806d92cdda55f96e36ed97ce1b1 (patch) | |
| tree | 5280dfb708e833e809a96065c44a122b1f57d622 /net | |
| parent | d1c7a6fea7a81dec9fcc5346bf3b879feedebba9 (diff) | |
| download | linux-237563f7d004f806d92cdda55f96e36ed97ce1b1.tar.gz linux-237563f7d004f806d92cdda55f96e36ed97ce1b1.tar.bz2 linux-237563f7d004f806d92cdda55f96e36ed97ce1b1.zip | |
SUNRPC: Address Kerberos performance/behavior regression
[ Upstream commit deaa5c96c2f7e8b934088a1e70a0fe8797bd1149 ]
When using Kerberos with v4.20, I've observed frequent connection
loss on heavy workloads. I traced it down to the client underrunning
the GSS sequence number window -- NFS servers are required to drop
the RPC with the low sequence number, and also drop the connection
to signal that an RPC was dropped.
Bisected to commit 918f3c1fe83c ("SUNRPC: Improve latency for
interactive tasks").
I've got a one-line workaround for this issue, which is easy to
backport to v4.20 while a more permanent solution is being derived.
Essentially, tk_owner-based sorting is disabled for RPCs that carry
a GSS sequence number.
Fixes: 918f3c1fe83c ("SUNRPC: Improve latency for interactive ... ")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'net')
| -rw-r--r-- | net/sunrpc/xprt.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c index 73547d17d3c6..943f08be7c38 100644 --- a/net/sunrpc/xprt.c +++ b/net/sunrpc/xprt.c @@ -1177,7 +1177,7 @@ xprt_request_enqueue_transmit(struct rpc_task *task) INIT_LIST_HEAD(&req->rq_xmit2); goto out; } - } else { + } else if (!req->rq_seqno) { list_for_each_entry(pos, &xprt->xmit_queue, rq_xmit) { if (pos->rq_task->tk_owner != task->tk_owner) continue; |