Hi Greg,

Are you going to apply this patch to the 5.3.y stable kernel? The patch is 
applicable there too.

Best regards,
Pavel Shilovsky

-----Original Message-----
From: Greg Kroah-Hartman <[email protected]> 
Sent: Sunday, September 29, 2019 6:56 AM
To: [email protected]
Cc: Greg Kroah-Hartman <[email protected]>; [email protected]; 
kbuild test robot <[email protected]>; Dan Carpenter <[email protected]>; 
Pavel Shilovskiy <[email protected]>; Steven French 
<[email protected]>; Aurelien Aptel <[email protected]>; Sasha Levin 
<[email protected]>
Subject: [PATCH 5.2 02/45] smb3: fix unmount hang in open_shroot

From: Steve French <[email protected]>

[ Upstream commit 96d9f7ed00b86104bf03adeffc8980897e9694ab ]

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")

This is version 2 of this patch. An earlier version of this patch "smb3: fix 
unmount hang in open_shroot" had a problem found by Dan.

Reported-by: kbuild test robot <[email protected]>
Reported-by: Dan Carpenter <[email protected]>

Suggested-by: Pavel Shilovsky <[email protected]>
Reviewed-by: Pavel Shilovsky <[email protected]>
Signed-off-by: Steve French <[email protected]>
CC: Aurelien Aptel <[email protected]>
CC: Stable <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
---
 fs/cifs/smb2ops.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c index 
42de31d206169..8ae8ef526b4a5 100644
--- a/fs/cifs/smb2ops.c
+++ b/fs/cifs/smb2ops.c
@@ -656,6 +656,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;
 
@@ -677,7 +686,7 @@ int open_shroot(unsigned int xid, struct cifs_tcon *tcon, 
struct cifs_fid *pfid)
 
        rc = SMB2_open_init(tcon, &rqst[0], &oplock, &oparms, &utf16_path);
        if (rc)
-               goto oshr_exit;
+               goto oshr_free;
        smb2_set_next_command(tcon, &rqst[0]);
 
        memset(&qi_iov, 0, sizeof(qi_iov));
@@ -690,18 +699,10 @@ int open_shroot(unsigned int xid, struct cifs_tcon *tcon, 
struct cifs_fid *pfid)
                                  sizeof(struct smb2_file_all_info) +
                                  PATH_MAX * 2, 0, NULL);
        if (rc)
-               goto oshr_exit;
+               goto oshr_free;
 
        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



Reply via email to