From patchwork Thu Sep 12 23:10:08 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steve French X-Patchwork-Id: 11143873 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id EDBD616B1 for ; Thu, 12 Sep 2019 23:10:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BC0FF2084D for ; Thu, 12 Sep 2019 23:10:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Yfdyl+RS" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726532AbfILXKW (ORCPT ); Thu, 12 Sep 2019 19:10:22 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:35494 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726230AbfILXKW (ORCPT ); Thu, 12 Sep 2019 19:10:22 -0400 Received: by mail-io1-f66.google.com with SMTP id f4so58164576ion.2 for ; Thu, 12 Sep 2019 16:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=jbEFJLXBj4+RrNqguBbv/s6oOBHNgnaaJwvXHPGnRic=; b=Yfdyl+RSLlUcIiM3VLw/lWlI+MvfzOp4l3spPrJNepyYuHeVr0+awEMdufMDQErH1e +9O7hDktK44yA4XVWtqAHNH8OXCTnPO3GuCDoXHj/IjFsOboKIjH0yG/+tGp4zIDav9I 0BieIjzL9enfcfclORmbBjDPMH8pHDBJm550UPfD+25EL90v0YLjNcZUIjM1u5qs1MlQ LK6/BRbjhUGgq1OBaXwQy44OXXcCd0H50EIHu5uqH53L92+9PxJEORURj9n6Xa9hIG8e AMjmuWNa1RbnCMAsLKDYXSSkZGxQjsp/Yr46k3vIiTzsEBs+f9DREDb8DiSY5hb5MBSI Gd8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=jbEFJLXBj4+RrNqguBbv/s6oOBHNgnaaJwvXHPGnRic=; b=dZbfIrfLPltwwkbiXmH2YnKDKcauo9rM6vcj+Lp9vf4gUI+4EMv0yA9x7TcvA7sMlE rJSMZdPtnZPRGvlDTu8qv20YbiREzpnhYCQ6vtUGdCnlG2cYRZlhrcuTKzWhRig9zMpI /RTTOZ7KSI4+WkweG5fC1gvDRXueeAyTVu8YSUTq3EwmiMCpHnjkFcKMpVey4GA88IFH PCpOa2ligAsNWkpJJlzKfU36H+q+qlCjTQBskaL9FK1CmvTrU2bHcfGAuK21R9SO2qrI ju/FJitZz3bBQBdudHCHvTT+BmyrCS+iilCBudgKAbIj2tmEcZZpFmNUbfYv9F79vPnM gvJw== X-Gm-Message-State: APjAAAUI576xjFUqmzO/9Pn9MNS5lcQ+namd7apCgQ9GoYWx8h0/Yj+J QJJnPvFnM6HqQQmbebD3UTZNVtvCwX9vX0KukEF/wWby X-Google-Smtp-Source: APXvYqxrt0ozdkHS2+mgDLZf1HPseqdGlRw6EU/IDVCCmwsqCYAnvEe0zBdM2KhzFwP4sz+BONL3fRWrtKTzf0XKXD8= X-Received: by 2002:a6b:c38f:: with SMTP id t137mr861740iof.137.1568329820728; Thu, 12 Sep 2019 16:10:20 -0700 (PDT) MIME-Version: 1.0 From: Steve French Date: Thu, 12 Sep 2019 18:10:08 -0500 Message-ID: Subject: [PATCH] smb3: fix unmount hang in open_shroot To: CIFS Cc: Pavel Shilovsky , =?utf-8?q?Aur=C3=A9lien_Aptel?= Sender: linux-cifs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-cifs@vger.kernel.org smb3: fix unmount hang in open_shroot An earlier patch "CIFS: fix deadlock in cached root handling" did not completely address the deadlock in open_shroot. This patch addresses the deadlock. In testing the recent patch: smb3: improve handling of share deleted (and share recreated) we were able to reproduce the open_shroot deadlock to one of the target servers in unmount in a delete share scenario. Fixes: 7e5a70ad88b1e ("CIFS: fix deadlock in cached root handling") Suggested-by: Pavel Shilovsky Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French CC: Aurelien Aptel CC: Stable Reviewed-by: Aurelien Aptel --- fs/cifs/smb2ops.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) @@ -696,14 +705,6 @@ int open_shroot(unsigned int xid, struct cifs_tcon *tcon, struct cifs_fid *pfid) smb2_set_related(&rqst[1]); - /* - * We do not hold the lock for the open because in case - * SMB2_open needs to reconnect, it will end up calling - * cifs_mark_open_files_invalid() which takes the lock again - * thus causing a deadlock - */ - - mutex_unlock(&tcon->crfid.fid_mutex); rc = compound_send_recv(xid, ses, flags, 2, rqst, resp_buftype, rsp_iov); mutex_lock(&tcon->crfid.fid_mutex); -- Thanks, Steve From 1f16bb0483a133882dc2f405dfcc26daa30b9117 Mon Sep 17 00:00:00 2001 From: Steve French Date: Thu, 12 Sep 2019 17:52:54 -0500 Subject: [PATCH] smb3: fix unmount hang in open_shroot An earlier patch "CIFS: fix deadlock in cached root handling" did not completely address the deadlock in open_shroot. This patch addresses the deadlock. In testing the recent patch: smb3: improve handling of share deleted (and share recreated) we were able to reproduce the open_shroot deadlock to one of the target servers in unmount in a delete share scenario. Fixes: 7e5a70ad88b1e ("CIFS: fix deadlock in cached root handling") Suggested-by: Pavel Shilovsky Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French CC: Aurelien Aptel CC: Stable --- fs/cifs/smb2ops.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c index 3672ce0bfbaf..150327ebb2b4 100644 --- a/fs/cifs/smb2ops.c +++ b/fs/cifs/smb2ops.c @@ -658,6 +658,15 @@ int open_shroot(unsigned int xid, struct cifs_tcon *tcon, struct cifs_fid *pfid) return 0; } + /* + * We do not hold the lock for the open because in case + * SMB2_open needs to reconnect, it will end up calling + * cifs_mark_open_files_invalid() which takes the lock again + * thus causing a deadlock + */ + + mutex_unlock(&tcon->crfid.fid_mutex); + if (smb3_encryption_required(tcon)) flags |= CIFS_TRANSFORM_REQ; @@ -696,14 +705,6 @@ int open_shroot(unsigned int xid, struct cifs_tcon *tcon, struct cifs_fid *pfid) smb2_set_related(&rqst[1]); - /* - * We do not hold the lock for the open because in case - * SMB2_open needs to reconnect, it will end up calling - * cifs_mark_open_files_invalid() which takes the lock again - * thus causing a deadlock - */ - - mutex_unlock(&tcon->crfid.fid_mutex); rc = compound_send_recv(xid, ses, flags, 2, rqst, resp_buftype, rsp_iov); mutex_lock(&tcon->crfid.fid_mutex); -- 2.20.1