Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1965214pxb; Mon, 22 Feb 2021 16:13:06 -0800 (PST) X-Google-Smtp-Source: ABdhPJw3gGn5X3Jd/AvrnYGIUl0y1rO5rvuGfJtdapKvP0h9V89YEy9bXIK3a8bKS4Yvrs7h0m2d X-Received: by 2002:a17:906:a287:: with SMTP id i7mr783542ejz.363.1614039186497; Mon, 22 Feb 2021 16:13:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614039186; cv=none; d=google.com; s=arc-20160816; b=glvnu3FPddRez9t4XI+in08GCj/edWsu2oEK8RLq8ezOMoY8SACz5G2bLSuC/HipFJ Y34At1qNE8xhbo41ZSGmbx4rlUEW29ili5E6hdOUSxvsnuUkPYI1u17PM6PR2BEnP7Sj wKvtgl+btle6+CZTtsklkz5ivZc+Nd2iXP27+a07dOrwjzs5go3Qb6upxvfLwsCIX5wA kWYpF6yODZ42KXGA05FieyGxAe966ww84yPF+/NGZL02Uq+B5+jtOkfoW5I1TKCXdJs6 7JsqITJdP+a82KrwboCmWGlV7X6gzeOIVYvy3cW63WQlHSikbq0D2qN5QmE9b4pyHMXU g5tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=tMLEVN/iD5cZUgWXeZ3iblLrucHf+nrkwFvf23GuuxM=; b=qY+Bur0W/lo5qHuhm/anUgtTZ2XQ5yugYcNNg5Ztucy+n0QX/Cul3le1cqVqCr+lsO Jo1Hofw2vAXnXAvT/zeKs1a07bxCseywaD76/diCvycQMSEOceCFzz1dWJOifhOKjv9H MED7ee37VIXKQ+Swe7ZMx+KaK5HEIouSn9qLxMSjEqVoUxDAOV3ZCzGJ2jkEas/7VKXu 9Ei+Pxzys/anKcD+cu5NrEQzAyPPBDEiBd3kIi2Y0V79EYr2m+AWeX4YLGU8o19P64Iz tY+Y+18kJhp7LQ/5bzy7KFwZo5SJ0+HgRck/xx3QqeD9MyZGEMPXNgANuppMqrEy1IQG 0AAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rothenpieler.org header.s=mail header.b=BJXzU3aV; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=rothenpieler.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ks21si5136263ejb.366.2021.02.22.16.12.31; Mon, 22 Feb 2021 16:13:06 -0800 (PST) Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@rothenpieler.org header.s=mail header.b=BJXzU3aV; spf=pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=rothenpieler.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230040AbhBVXhO (ORCPT + 99 others); Mon, 22 Feb 2021 18:37:14 -0500 Received: from btbn.de ([5.9.118.179]:51364 "EHLO btbn.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229996AbhBVXhN (ORCPT ); Mon, 22 Feb 2021 18:37:13 -0500 Received: from Kryux.localdomain (muedsl-82-207-198-025.citykom.de [82.207.198.25]) by btbn.de (Postfix) with ESMTPSA id CD4B811E981; Tue, 23 Feb 2021 00:36:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rothenpieler.org; s=mail; t=1614036991; bh=tMLEVN/iD5cZUgWXeZ3iblLrucHf+nrkwFvf23GuuxM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=BJXzU3aVu7/k+g30eDBdmLiAemUYmhG6HtM4y8kTPcNbiqNmRdOzaqUilRLEiCa5C eWmaE1Opu3LITO2YlsjiqN/xyKF8yoMyDZ4Qm9AdVGULpthKY9F8s2V+e5tADSs6kx KH+y4KN+KbQzorvjJUPY5hApi5bl0KS12b/EAoz4SOaZC96wSiXXCPvFHbjaJVc8HP KGnzqugUBj+ORKPuY6HsJupThRDtVtt0SWYja8l0mEvbRtsVPY1AksGZr8BK9oQBLB hRllRT9mqONYAKbiniwcb3RSW6PmJlgdIMTV/QcRhCnJl9eTQh3smxD/IgndDElVTl kGn1UM7gntfOQ== From: Timo Rothenpieler To: Linux NFS Mailing List Cc: Chuck Lever , Olga Kornievskaia , Dai Ngo , Timo Rothenpieler Subject: [PATCH] svcrdma: disable timeouts on rdma backchannel Date: Tue, 23 Feb 2021 00:36:19 +0100 Message-Id: <20210222233619.21568-1-timo@rothenpieler.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org This brings it in line with the regular tcp backchannel, which also has all those timeouts disabled. Prevents the backchannel from timing out, getting some async operations like server side copying getting stuck indefinitely on the client side. Signed-off-by: Timo Rothenpieler --- Did the same testing with this applied than before, and could not observe it getting stuck, same as with the previous patch, which I removed before testing this one. This obviously still does not fix the issue of it being seemingly unable to reestablish the disconnected backchannel. An event that disconnects the backchannel but leaves the main connection intact seems a pretty rare occurance though, outside of this issue. net/sunrpc/xprtrdma/svc_rdma_backchannel.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c index 63f8be974df2..8186ab6f99f1 100644 --- a/net/sunrpc/xprtrdma/svc_rdma_backchannel.c +++ b/net/sunrpc/xprtrdma/svc_rdma_backchannel.c @@ -252,9 +252,9 @@ xprt_setup_rdma_bc(struct xprt_create *args) xprt->timeout = &xprt_rdma_bc_timeout; xprt_set_bound(xprt); xprt_set_connected(xprt); - xprt->bind_timeout = RPCRDMA_BIND_TO; - xprt->reestablish_timeout = RPCRDMA_INIT_REEST_TO; - xprt->idle_timeout = RPCRDMA_IDLE_DISC_TO; + xprt->bind_timeout = 0; + xprt->reestablish_timeout = 0; + xprt->idle_timeout = 0; xprt->prot = XPRT_TRANSPORT_BC_RDMA; xprt->ops = &xprt_rdma_bc_procs; -- 2.25.1