Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp281313pxj; Tue, 18 May 2021 03:18:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwN6BiAKQosdcBY9DYUlnqiD5xgEnyCSglLc3HmLnmx51gx/UTXq9cSb3Dy/v97E/FcQHrH X-Received: by 2002:a17:906:ecf9:: with SMTP id qt25mr5274967ejb.55.1621333105269; Tue, 18 May 2021 03:18:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621333105; cv=none; d=google.com; s=arc-20160816; b=X0BOeT2/oKcLXsSrN9NDLnx0Taq3yjymfEfFtvHZ7LgXhpiSEp9UGBNTTHhbMUjS38 FH0FeKPgdWWs9nf7a7CQJA36bv1pe+eseZjWrJLOzuwjToQArq7nyE26wxFBJS4F8sya n17SwuJCgRmR5BM/RQBuoqy97+5aSYp79ox3v522/x743XaFbj6gt3QZpMh24GvHoXph Drm6pLS4CekeI/+QPW5sZzq8V+95lzglzmTxiTxnVN1IvEaoMSUvQUIYDfYC1VF+PTxG b7r1a/TJcTFmg1d+O9eQN3hoe/QTwEExHsySkOFpPJn15oC9FmsF7Q5VubIAv6x0IvXj JRoA== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=FKKbbcLShBgjih48wMWUcjaGUJZ8kWy5EQJ/hjbAy54=; b=NJ5EZVZMeFoZP9/COkSUJogXEZ6kiHTf+hJgSQxpth2a3k4cmv5PWknjaDo7/ehEIS UafsHLTD9gtg9+a+QEsv3WaG48SsXKvoUAcxmnyKksoMnulJGUqNjptBTFeMXMtfN+OD GKxdRBd+Vj6LFyd74ArAqqz+ef4Tx6ISPJ0gMTlkS1TUc7Hq/3R/Vha95XWQN/Ql6nac JbinVaoLO4yod4pvYNYyVBWX2CvWpWNjqfPQvOOUSHwNMuin8CbltV6uqX/2U9gHSZJG gu8BYK897aix5XL9mOxTkM/9t+Dckb6VoBqJ4yEdlxSn29snwpxpxETLyyQGBouHof3i UVGg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="i/az1CYa"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p10si17490630ejo.39.2021.05.18.03.18.01; Tue, 18 May 2021 03:18:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-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=@linuxfoundation.org header.s=korg header.b="i/az1CYa"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243037AbhEQPNI (ORCPT + 99 others); Mon, 17 May 2021 11:13:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:34130 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242531AbhEQPDu (ORCPT ); Mon, 17 May 2021 11:03:50 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 93E4861377; Mon, 17 May 2021 14:27:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1621261680; bh=3IjUhckdqDInYS9wKOMOIf9azJ1uG6SRWO0KmbO6Dts=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=i/az1CYaO6cCrU8jUnV2WUVoc9gGBQ33zZQshJeeEX3qWB51/A8Kh2vk3mxsb/cxV PruR6lrzF/7oAeEMYzO4bNpF3DlREkKmPBq7FcUFppbgoRQiIXcfHbNkluPCwaaa/p TS8Zlgq4x26/qEJsKrU9L1KYThfk2ftpjx7RRIRs= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Chris Dion , Trond Myklebust , Sasha Levin Subject: [PATCH 5.11 149/329] SUNRPC: Handle major timeout in xprt_adjust_timeout() Date: Mon, 17 May 2021 16:01:00 +0200 Message-Id: <20210517140307.154245447@linuxfoundation.org> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20210517140302.043055203@linuxfoundation.org> References: <20210517140302.043055203@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Chris Dion [ Upstream commit 09252177d5f924f404551b4b4eded5daa7f04a3a ] Currently if a major timeout value is reached, but the minor value has not been reached, an ETIMEOUT will not be sent back to the caller. This can occur if the v4 server is not responding to requests and retrans is configured larger than the default of two. For example, A TCP mount with a configured timeout value of 50 and a retransmission count of 3 to a v4 server which is not responding: 1. Initial value and increment set to 5s, maxval set to 20s, retries at 3 2. Major timeout is set to 20s, minor timeout set to 5s initially 3. xport_adjust_timeout() is called after 5s, retry with 10s timeout, minor timeout is bumped to 10s 4. And again after another 10s, 15s total time with minor timeout set to 15s 5. After 20s total time xport_adjust_timeout is called as major timeout is reached, but skipped because the minor timeout is not reached - After this time the cpu spins continually calling xport_adjust_timeout() and returning 0 for 10 seconds. As seen on perf sched: 39243.913182 [0005] mount.nfs[3794] 4607.938 0.017 9746.863 6. This continues until the 15s minor timeout condition is reached (in this case for 10 seconds). After which the ETIMEOUT is processed back to the caller, the cpu spinning stops, and normal operations continue Fixes: 7de62bc09fe6 ("SUNRPC dont update timeout value on connection reset") Signed-off-by: Chris Dion Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin --- net/sunrpc/xprt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c index 11ebe8a127b8..20fe31b1b776 100644 --- a/net/sunrpc/xprt.c +++ b/net/sunrpc/xprt.c @@ -698,9 +698,9 @@ int xprt_adjust_timeout(struct rpc_rqst *req) const struct rpc_timeout *to = req->rq_task->tk_client->cl_timeout; int status = 0; - if (time_before(jiffies, req->rq_minortimeo)) - return status; if (time_before(jiffies, req->rq_majortimeo)) { + if (time_before(jiffies, req->rq_minortimeo)) + return status; if (to->to_exponential) req->rq_timeout <<= 1; else -- 2.30.2