SUNRPC: Address Kerberos performance/behavior regression

chucklever · amschuma-ntap · commit deaa5c96c2f7 · 2019-01-15T15:36:41.000-05:00
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 918f3c1 ("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: 918f3c1 ("SUNRPC: Improve latency for interactive ... ") Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
@@ -1178,7 +1178,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;

Original file line number	Diff line number	Diff line change
`@@ -1178,7 +1178,7 @@ xprt_request_enqueue_transmit(struct rpc_task *task)`
`1178`	`1178`	`INIT_LIST_HEAD(&req->rq_xmit2);`
`1179`	`1179`	`goto out;`
`1180`	`1180`	`}`
`1181`		`- } else {`
	`1181`	`+ } else if (!req->rq_seqno) {`
`1182`	`1182`	`list_for_each_entry(pos, &xprt->xmit_queue, rq_xmit) {`
`1183`	`1183`	`if (pos->rq_task->tk_owner != task->tk_owner)`
`1184`	`1184`	`continue;`