Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4565076imu; Tue, 29 Jan 2019 03:54:54 -0800 (PST) X-Google-Smtp-Source: ALg8bN7OiJlC+8vor/HF8X90/x9bOGGpmMAHdHoIFmrtDUd3KgvitPa/9pkwdarjtIEwmQWOOks4 X-Received: by 2002:a17:902:12f:: with SMTP id 44mr26072327plb.74.1548762894291; Tue, 29 Jan 2019 03:54:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548762894; cv=none; d=google.com; s=arc-20160816; b=dmbAbgvHQ9z7oodSMeMl0J0kkGuqMBNHYKTnhgYLCylUPctdE5EidwCeISaD11JJl1 w0huJ4avfG1lNFGl1Jjm6DhrKbdIXethM6VXfIDqaRsHJjdDyQsa+TdS4sb3/uxfqYfM mXPmBBW+UvH0F7NIg+5yAERo2iuaha/3yJu+beLIa0eOv93hCgETxGAG0kwaqk7avLpN rKjinkLT0Ni7OxQnOIE8Yu3U4wfUcfrOAwCeD8IXAHHzsI002qKD9iol/vXQc6DSKtiw AvHsYHrSc2N8K4xr0bjYApAt50jrYo1QsTNIkZ5CotP7wemijduiS8OuoTBYpJAZ5V10 BfiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=J9dVoe2jFdRh9q3nbfm3FmdHJU9ZA+62EYIwJ3qZwi0=; b=lA3Fu5K57C5Q5RIDnUsDsFZF0Fc/y87Ma69OzTKFMolKZzZUFVtR949Oui0q4EmzcE aGEarplKHouA8x1XJIX54SWtpoK1m6bAFwtvcOmkNAlhgyaRlDGlN0Lwtjo+6VM8OyI9 azcDi0a4br2ngQM5rGPR3EcUS6O8rWV4dGUr3EVd94v1GM08OYYfHyPspswS1xE3nMzE XNZO2pOlEH6JfWEhYmP8ohOE4Rs8h3FsWTnVrC7kRxpzd3N3AkPDaUSxYffTYGqkK2tt RGhEjjbx959KLTJUhTKCHyyduTTL9Xum5cWBe9+kgXWEbQRzHbs4voYpqUs/YF2grCSQ 1HTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="UtGjZj/d"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m7si2151800pgi.547.2019.01.29.03.54.38; Tue, 29 Jan 2019 03:54:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="UtGjZj/d"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731683AbfA2LxF (ORCPT + 99 others); Tue, 29 Jan 2019 06:53:05 -0500 Received: from mail.kernel.org ([198.145.29.99]:44524 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731845AbfA2Lwi (ORCPT ); Tue, 29 Jan 2019 06:52:38 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 705FC2083B; Tue, 29 Jan 2019 11:52:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1548762757; bh=c3VauOQN45qEG/SM+mEC95pDVBUJqXulfmhN7arytrs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UtGjZj/dsMb5IvGsW2aRR81MYbrycSA2Cl8VUyTLUWQUP9EIrHKUoZ5oHwt2XYRcr 6mdRqO4WvYSuSJqM2vjzyukj5ZpZobXb/8DA6BACqblxAmXfBoWB3BykZOrZYq7rCu oxaExPO2mf2Za9wo9scmlqdHFdwWbRRmMdT1rR34= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Pavel Shilovsky , Steve French Subject: [PATCH 4.9 22/44] CIFS: Fix possible hang during async MTU reads and writes Date: Tue, 29 Jan 2019 12:36:17 +0100 Message-Id: <20190129113141.745926602@linuxfoundation.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190129113139.826927690@linuxfoundation.org> References: <20190129113139.826927690@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Pavel Shilovsky commit acc58d0bab55a50e02c25f00bd6a210ee121595f upstream. When doing MTU i/o we need to leave some credits for possible reopen requests and other operations happening in parallel. Currently we leave 1 credit which is not enough even for reopen only: we need at least 2 credits if durable handle reconnect fails. Also there may be other operations at the same time including compounding ones which require 3 credits at a time each. Fix this by leaving 8 credits which is big enough to cover most scenarios. Was able to reproduce this when server was configured to give out fewer credits than usual. The proper fix would be to reconnect a file handle first and then obtain credits for an MTU request but this leads to bigger code changes and should happen in other patches. Cc: Signed-off-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman --- fs/cifs/smb2ops.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/fs/cifs/smb2ops.c +++ b/fs/cifs/smb2ops.c @@ -148,14 +148,14 @@ smb2_wait_mtu_credits(struct TCP_Server_ scredits = server->credits; /* can deadlock with reopen */ - if (scredits == 1) { + if (scredits <= 8) { *num = SMB2_MAX_BUFFER_SIZE; *credits = 0; break; } - /* leave one credit for a possible reopen */ - scredits--; + /* leave some credits for reopen and other ops */ + scredits -= 8; *num = min_t(unsigned int, size, scredits * SMB2_MAX_BUFFER_SIZE);