Received: by 2002:ac0:8c9a:0:0:0:0:0 with SMTP id r26csp3642930ima; Mon, 4 Feb 2019 02:41:06 -0800 (PST) X-Google-Smtp-Source: AHgI3IYlhEoRkK+vfvDZeOid0/s2h7bacpA3G1t9kxWIWmv6J33EJFwJzI16yFZGDplIvSplngaj X-Received: by 2002:a63:d54a:: with SMTP id v10mr3797716pgi.154.1549276866404; Mon, 04 Feb 2019 02:41:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549276866; cv=none; d=google.com; s=arc-20160816; b=YIE6rsczQQ2IZGvryia8YQ7imS1sYdz2vDFUJPU0qP/x4jzFpRSPg1tR2BJgACgqXb NR4IFRWqgVoVsFZ42yA7Qpl1QzrkbMph5kIIuATQ6xL5jzCjyc5YXm3i51zEO6/ZX+63 bxL7OWbEpyyvo7Nz6goJb8vhAanZ9grjsTKE96FkHzla4omn5UxvM4VjZMmVXQEO3y6l F46hNZQuVc+1nFDncBseqTvsUYTjYOaTQTqhdhWN2fKHp1NmFEYvXIp52Sus4j6TwZ4N xL4zB869UWhrwA/EjZw5ORUd8xfDHNNqUEE90zBLPDkqu0W7llL9vDwg+0FR86noQLIu SDzQ== 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=6VMoHp8zB3KnoUvOMgqAlzMBmkgTJUBw0gdcWslq2/o=; b=omCI9GK8zaf3HfP4+LhARnFY3eQIT/2/KrIM7LQqYWCLHuvt7Sa2R06CuSRF6uhqds Ue+8EnFy85yl8aSBqi8M3LwDxnzkgFz/yeRjbtDnb/GhN1ivrF5oshie8tye1vaFP3qz 3K163XYPKF5mjlIwdoQKaN6xWyP57W4a7fsHlo7sT8+GHV00C/P/KFAOnGpKC8zySV4L qpdJDOOqN8OO+NAIKrQoqZIgPSR9Q/patU4+4i8KerVOzGENLHaDqaXMVOU1w93rJ8JS HCP9fsR4RKV3gr3dAu1mfmSVCAgbhSYStIzqR7+X9NDc1l9WNbGHxoylPpaJWOlCNfg3 jMmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=Q6rf417x; 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 e35si3044623pgb.548.2019.02.04.02.40.50; Mon, 04 Feb 2019 02:41:06 -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=Q6rf417x; 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 S1729882AbfBDKjz (ORCPT + 99 others); Mon, 4 Feb 2019 05:39:55 -0500 Received: from mail.kernel.org ([198.145.29.99]:37910 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729837AbfBDKjy (ORCPT ); Mon, 4 Feb 2019 05:39:54 -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 5D4F72075B; Mon, 4 Feb 2019 10:39:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1549276793; bh=wDiZCf4UOt3KFowd2RTqJe374vWRZY/KVFXFq5Ir8u0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Q6rf417x1QCakN7WeQReYb6JdbfacvgAoNeYg8nFNViQDFDWmsApYG2CKhwgqKzva 6lGTRRlaLuLwbCDb6XlhvKQMsNZq97Z9PD1OzbA5DlCYYcR+rcDmX23MTdCFfEU60F d/ynHjxSsuuvRpZRZMNv6y1Fm5VLG5XxL/700/Ao= 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.4 17/65] CIFS: Fix possible hang during async MTU reads and writes Date: Mon, 4 Feb 2019 11:36:10 +0100 Message-Id: <20190204103613.304866636@linuxfoundation.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190204103610.583715954@linuxfoundation.org> References: <20190204103610.583715954@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.4-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 @@ -143,14 +143,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);