Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4137373pxb; Mon, 8 Feb 2021 08:47:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJylByuIc4/dHFL9thcQr3goaa9Cyqbs1jMUVqWyB8vicfVBzho2bzZjTBi1O7/xox+zcil/ X-Received: by 2002:a17:906:4c85:: with SMTP id q5mr17652147eju.375.1612802860686; Mon, 08 Feb 2021 08:47:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612802860; cv=none; d=google.com; s=arc-20160816; b=B+Oj3TRd7OKo7q4gxZdix9605U6e3E6kXmNAK7wr1BnxL6vzoEuaaboo1iVRVvEj4z CKo9Oxa8Btu3lbymn2onqBklUkxdli+lEuI8W4G0kDMzMdJFLbT835/3LgN/7Cd0Xkky 5zzGhw4YmMQX58euNQwPQz7I6sYWNiQ4wYa9FfN1IOaKwXj9hlSYk+3GWKFSEFKBuY7I BacL2Me09ALZydk1yW23tXlzX5q9zkdf8UGbz3FQQPdyaOWyphyZuURBYAkZgPxCot0w gaoradE7wV/5VOM3K6C/Z6GaBGhbq9yEt+IuCk1HWZaSpQBobtk2c7H2EHoWkgOUo6xJ jNuw== 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=F1GV5fiNuRDQj9w+1YJtxCf7J9yblEVHD6KDFhrBrWY=; b=u/6m3E92nrfCdY9sAmN+pLO2WLZ4p1ntFsTLObmt17vvTmcVWZvXVM84MdCnz1G63S 4wTImsbNo8OAdT2HD7fE+DhTuIe6x3KyKpN4Pt7fvHHXe+/88xXWi2cnLvo3IrW49HJz TmvlQmjWXluZz0m6lXz9xw3nfOe5z/uLo26kkgvUcjOmH1d/0dCSKsGU/iS1actEdADo kQ8ot56NFLeLN2HbSTWKSgb/nItL/wXcN1iYjE74pPl0qnnPrRj3vOmUgEjP6TQJ0nMm QriFtG4vjkmuIMnOst8KXplsg+2AIeRtGgQ3pyao4be48BiDAmltt0wq8smlbOSBwSvq z4hA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=dLS8uddC; 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 sb22si8424940ejb.268.2021.02.08.08.47.14; Mon, 08 Feb 2021 08:47:40 -0800 (PST) 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=dLS8uddC; 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 S234489AbhBHQoi (ORCPT + 99 others); Mon, 8 Feb 2021 11:44:38 -0500 Received: from mail.kernel.org ([198.145.29.99]:56626 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233517AbhBHPOt (ORCPT ); Mon, 8 Feb 2021 10:14:49 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 5F4FD64ECB; Mon, 8 Feb 2021 15:10:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1612797050; bh=PJ6Jtig7KPgqGEEqxQ1Xnv6Kxjj3F3qRz2LrumFTtHs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dLS8uddC6cEtlBkhT34FXlkniNApHseNyxJvsW376e0KisizPotmAJ1kwK76oppZw 6GWAOPeFZwchwayxTKvtgxi6tTyxWyKbFjZSsZDGifx+HSgpCLg1sN2RyXUxDsi/YO D3sGDU+A+9X4aFLNelmNanoZLCAXptpZSrZXIwwI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pavel Shilovsky , Tom Talpey , Shyam Prasad N , Steve French Subject: [PATCH 5.4 41/65] smb3: fix crediting for compounding when only one request in flight Date: Mon, 8 Feb 2021 16:01:13 +0100 Message-Id: <20210208145811.812309797@linuxfoundation.org> X-Mailer: git-send-email 2.30.0 In-Reply-To: <20210208145810.230485165@linuxfoundation.org> References: <20210208145810.230485165@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: Pavel Shilovsky commit 91792bb8089b63b7b780251eb83939348ac58a64 upstream. Currently we try to guess if a compound request is going to succeed waiting for credits or not based on the number of requests in flight. This approach doesn't work correctly all the time because there may be only one request in flight which is going to bring multiple credits satisfying the compound request. Change the behavior to fail a request only if there are no requests in flight at all and proceed waiting for credits otherwise. Cc: # 5.1+ Signed-off-by: Pavel Shilovsky Reviewed-by: Tom Talpey Reviewed-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman --- fs/cifs/transport.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) --- a/fs/cifs/transport.c +++ b/fs/cifs/transport.c @@ -659,10 +659,22 @@ wait_for_compound_request(struct TCP_Ser spin_lock(&server->req_lock); if (*credits < num) { /* - * Return immediately if not too many requests in flight since - * we will likely be stuck on waiting for credits. + * If the server is tight on resources or just gives us less + * credits for other reasons (e.g. requests are coming out of + * order and the server delays granting more credits until it + * processes a missing mid) and we exhausted most available + * credits there may be situations when we try to send + * a compound request but we don't have enough credits. At this + * point the client needs to decide if it should wait for + * additional credits or fail the request. If at least one + * request is in flight there is a high probability that the + * server will return enough credits to satisfy this compound + * request. + * + * Return immediately if no requests in flight since we will be + * stuck on waiting for credits. */ - if (server->in_flight < num - *credits) { + if (server->in_flight == 0) { spin_unlock(&server->req_lock); return -ENOTSUPP; }