diff mbox series

[SMB3] Fix share deleted and share recreated cases

Message ID CAH2r5mtFA5c5XxL6ohwyGqj=zPc0mUR1_VNvcMyhrZZJuwcBPA@mail.gmail.com (mailing list archive)
State New, archived
Headers show
Series [SMB3] Fix share deleted and share recreated cases | expand

Commit Message

Steve French Sept. 11, 2019, 5:13 a.m. UTC 
When a share is deleted, returning EIO is confusing and no useful
information is logged.  Improve the handling of this case by
at least logging a better error for this (and also mapping the error
differently to EREMCHG).  See e.g. the new messages that would be logged:

[55243.639530] server share \\192.168.1.219\scratch deleted
[55243.642568] CIFS VFS: \\192.168.1.219\scratch BAD_NETWORK_NAME:
\\192.168.1.219\scratch

In addition for the case where a share is deleted and then recreated
with the same name, have now fixed that so it works. This is sometimes
done for example, because the admin had to move a share to a different,
bigger local drive when a share is running low on space.

Comments

ronnie sahlberg Sept. 11, 2019, 5:24 a.m. UTC | #1 
Looks good.


We also need to handle the case where the share is deleted but is
never added back.

On Wed, Sep 11, 2019 at 3:15 PM Steve French <smfrench@gmail.com> wrote:
>
> When a share is deleted, returning EIO is confusing and no useful
> information is logged.  Improve the handling of this case by
> at least logging a better error for this (and also mapping the error
> differently to EREMCHG).  See e.g. the new messages that would be logged:
>
> [55243.639530] server share \\192.168.1.219\scratch deleted
> [55243.642568] CIFS VFS: \\192.168.1.219\scratch BAD_NETWORK_NAME:
> \\192.168.1.219\scratch
>
> In addition for the case where a share is deleted and then recreated
> with the same name, have now fixed that so it works. This is sometimes
> done for example, because the admin had to move a share to a different,
> bigger local drive when a share is running low on space.
>
> --
> Thanks,
>
> Steve
Pavel Shilovsky Sept. 11, 2019, 5:08 p.m. UTC | #2 
can this error code be returned on any operation?
--
Best regards,
Pavel Shilovsky

вт, 10 сент. 2019 г. в 22:26, ronnie sahlberg <ronniesahlberg@gmail.com>:
>
> Looks good.
>
>
> We also need to handle the case where the share is deleted but is
> never added back.
>
> On Wed, Sep 11, 2019 at 3:15 PM Steve French <smfrench@gmail.com> wrote:
> >
> > When a share is deleted, returning EIO is confusing and no useful
> > information is logged.  Improve the handling of this case by
> > at least logging a better error for this (and also mapping the error
> > differently to EREMCHG).  See e.g. the new messages that would be logged:
> >
> > [55243.639530] server share \\192.168.1.219\scratch deleted
> > [55243.642568] CIFS VFS: \\192.168.1.219\scratch BAD_NETWORK_NAME:
> > \\192.168.1.219\scratch
> >
> > In addition for the case where a share is deleted and then recreated
> > with the same name, have now fixed that so it works. This is sometimes
> > done for example, because the admin had to move a share to a different,
> > bigger local drive when a share is running low on space.
> >
> > --
> > Thanks,
> >
> > Steve
ronnie sahlberg Sept. 11, 2019, 10:10 p.m. UTC | #3 
On Thu, Sep 12, 2019 at 3:08 AM Pavel Shilovsky <piastryyy@gmail.com> wrote:
>
> can this error code be returned on any operation?

Not sure.
I think it is only returned by TreeConnect and possibly also
SessionSetup, but not sure.


> --
> Best regards,
> Pavel Shilovsky
>
> вт, 10 сент. 2019 г. в 22:26, ronnie sahlberg <ronniesahlberg@gmail.com>:
> >
> > Looks good.
> >
> >
> > We also need to handle the case where the share is deleted but is
> > never added back.
> >
> > On Wed, Sep 11, 2019 at 3:15 PM Steve French <smfrench@gmail.com> wrote:
> > >
> > > When a share is deleted, returning EIO is confusing and no useful
> > > information is logged.  Improve the handling of this case by
> > > at least logging a better error for this (and also mapping the error
> > > differently to EREMCHG).  See e.g. the new messages that would be logged:
> > >
> > > [55243.639530] server share \\192.168.1.219\scratch deleted
> > > [55243.642568] CIFS VFS: \\192.168.1.219\scratch BAD_NETWORK_NAME:
> > > \\192.168.1.219\scratch
> > >
> > > In addition for the case where a share is deleted and then recreated
> > > with the same name, have now fixed that so it works. This is sometimes
> > > done for example, because the admin had to move a share to a different,
> > > bigger local drive when a share is running low on space.
> > >
> > > --
> > > Thanks,
> > >
> > > Steve
Pavel Shilovsky Sept. 12, 2019, 5:01 p.m. UTC | #4 
We need to skip TreeDisconnect command if tcon->need_reconnect is
true. Steve, could you add this to the patch?
--
Best regards,
Pavel Shilovsky

ср, 11 сент. 2019 г. в 15:10, ronnie sahlberg <ronniesahlberg@gmail.com>:
>
> On Thu, Sep 12, 2019 at 3:08 AM Pavel Shilovsky <piastryyy@gmail.com> wrote:
> >
> > can this error code be returned on any operation?
>
> Not sure.
> I think it is only returned by TreeConnect and possibly also
> SessionSetup, but not sure.
>
>
> > --
> > Best regards,
> > Pavel Shilovsky
> >
> > вт, 10 сент. 2019 г. в 22:26, ronnie sahlberg <ronniesahlberg@gmail.com>:
> > >
> > > Looks good.
> > >
> > >
> > > We also need to handle the case where the share is deleted but is
> > > never added back.
> > >
> > > On Wed, Sep 11, 2019 at 3:15 PM Steve French <smfrench@gmail.com> wrote:
> > > >
> > > > When a share is deleted, returning EIO is confusing and no useful
> > > > information is logged.  Improve the handling of this case by
> > > > at least logging a better error for this (and also mapping the error
> > > > differently to EREMCHG).  See e.g. the new messages that would be logged:
> > > >
> > > > [55243.639530] server share \\192.168.1.219\scratch deleted
> > > > [55243.642568] CIFS VFS: \\192.168.1.219\scratch BAD_NETWORK_NAME:
> > > > \\192.168.1.219\scratch
> > > >
> > > > In addition for the case where a share is deleted and then recreated
> > > > with the same name, have now fixed that so it works. This is sometimes
> > > > done for example, because the admin had to move a share to a different,
> > > > bigger local drive when a share is running low on space.
> > > >
> > > > --
> > > > Thanks,
> > > >
> > > > Steve
Steve French Sept. 13, 2019, 12:50 a.m. UTC | #5 
Fixed with a different patch following Pavel's suggestion - (a
followon to Aurelien's open_shroot hang patch)

On Thu, Sep 12, 2019 at 12:01 PM Pavel Shilovsky <piastryyy@gmail.com> wrote:
>
> We need to skip TreeDisconnect command if tcon->need_reconnect is
> true. Steve, could you add this to the patch?
> --
> Best regards,
> Pavel Shilovsky
>
> ср, 11 сент. 2019 г. в 15:10, ronnie sahlberg <ronniesahlberg@gmail.com>:
> >
> > On Thu, Sep 12, 2019 at 3:08 AM Pavel Shilovsky <piastryyy@gmail.com> wrote:
> > >
> > > can this error code be returned on any operation?
> >
> > Not sure.
> > I think it is only returned by TreeConnect and possibly also
> > SessionSetup, but not sure.
> >
> >
> > > --
> > > Best regards,
> > > Pavel Shilovsky
> > >
> > > вт, 10 сент. 2019 г. в 22:26, ronnie sahlberg <ronniesahlberg@gmail.com>:
> > > >
> > > > Looks good.
> > > >
> > > >
> > > > We also need to handle the case where the share is deleted but is
> > > > never added back.
> > > >
> > > > On Wed, Sep 11, 2019 at 3:15 PM Steve French <smfrench@gmail.com> wrote:
> > > > >
> > > > > When a share is deleted, returning EIO is confusing and no useful
> > > > > information is logged.  Improve the handling of this case by
> > > > > at least logging a better error for this (and also mapping the error
> > > > > differently to EREMCHG).  See e.g. the new messages that would be logged:
> > > > >
> > > > > [55243.639530] server share \\192.168.1.219\scratch deleted
> > > > > [55243.642568] CIFS VFS: \\192.168.1.219\scratch BAD_NETWORK_NAME:
> > > > > \\192.168.1.219\scratch
> > > > >
> > > > > In addition for the case where a share is deleted and then recreated
> > > > > with the same name, have now fixed that so it works. This is sometimes
> > > > > done for example, because the admin had to move a share to a different,
> > > > > bigger local drive when a share is running low on space.
> > > > >
> > > > > --
> > > > > Thanks,
> > > > >
> > > > > Steve
diff mbox series

Patch

From 5bcb0717d45d41be27741d00708341c6e81e680e Mon Sep 17 00:00:00 2001
From: Steve French <stfrench@microsoft.com>
Date: Wed, 11 Sep 2019 00:07:36 -0500
Subject: [PATCH] smb3: improve handling of share deleted (and share recreated)

When a share is deleted, returning EIO is confusing and no useful
information is logged.  Improve the handling of this case by
at least logging a better error for this (and also mapping the error
differently to EREMCHG).  See e.g. the new messages that would be logged:

[55243.639530] server share \\192.168.1.219\scratch deleted
[55243.642568] CIFS VFS: \\192.168.1.219\scratch BAD_NETWORK_NAME: \\192.168.1.219\scratch

In addition for the case where a share is deleted and then recreated
with the same name, have now fixed that so it works. This is sometimes
done for example, because the admin had to move a share to a different,
bigger local drive when a share is running low on space.

Signed-off-by: Steve French <stfrench@microsoft.com>
---
 fs/cifs/smb2inode.c    |  6 ++++++
 fs/cifs/smb2maperror.c |  2 +-
 fs/cifs/smb2ops.c      | 13 ++++++++++++-
 fs/cifs/smb2pdu.c      |  5 +++++
 4 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/fs/cifs/smb2inode.c b/fs/cifs/smb2inode.c
index c866555b6278..d2a3fb7e5c8d 100644
--- a/fs/cifs/smb2inode.c
+++ b/fs/cifs/smb2inode.c
@@ -335,6 +335,12 @@  smb2_compound_op(const unsigned int xid, struct cifs_tcon *tcon,
 		cifsFileInfo_put(cfile);
 
 	SMB2_open_free(&rqst[0]);
+	if (rc == -EREMCHG) {
+		printk_once(KERN_WARNING "server share %s deleted\n",
+			    tcon->treeName);
+		tcon->need_reconnect = true;
+	}
+
 	switch (command) {
 	case SMB2_OP_QUERY_INFO:
 		if (rc == 0) {
diff --git a/fs/cifs/smb2maperror.c b/fs/cifs/smb2maperror.c
index 82ade16c9501..7fde3775cb57 100644
--- a/fs/cifs/smb2maperror.c
+++ b/fs/cifs/smb2maperror.c
@@ -511,7 +511,7 @@  static const struct status_to_posix_error smb2_error_map_table[] = {
 	{STATUS_PRINT_QUEUE_FULL, -EIO, "STATUS_PRINT_QUEUE_FULL"},
 	{STATUS_NO_SPOOL_SPACE, -EIO, "STATUS_NO_SPOOL_SPACE"},
 	{STATUS_PRINT_CANCELLED, -EIO, "STATUS_PRINT_CANCELLED"},
-	{STATUS_NETWORK_NAME_DELETED, -EIO, "STATUS_NETWORK_NAME_DELETED"},
+	{STATUS_NETWORK_NAME_DELETED, -EREMCHG, "STATUS_NETWORK_NAME_DELETED"},
 	{STATUS_NETWORK_ACCESS_DENIED, -EACCES, "STATUS_NETWORK_ACCESS_DENIED"},
 	{STATUS_BAD_DEVICE_TYPE, -EIO, "STATUS_BAD_DEVICE_TYPE"},
 	{STATUS_BAD_NETWORK_NAME, -ENOENT, "STATUS_BAD_NETWORK_NAME"},
diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
index 9b74149b471f..3672ce0bfbaf 100644
--- a/fs/cifs/smb2ops.c
+++ b/fs/cifs/smb2ops.c
@@ -741,8 +741,14 @@  int open_shroot(unsigned int xid, struct cifs_tcon *tcon, struct cifs_fid *pfid)
 
 	/* Cached root is still invalid, continue normaly */
 
-	if (rc)
+	if (rc) {
+		if (rc == -EREMCHG) {
+			tcon->need_reconnect = true;
+			printk_once(KERN_WARNING "server share %s deleted\n",
+				    tcon->treeName);
+		}
 		goto oshr_exit;
+	}
 
 	o_rsp = (struct smb2_create_rsp *)rsp_iov[0].iov_base;
 	oparms.fid->persistent_fid = o_rsp->PersistentFileId;
@@ -2237,6 +2243,11 @@  smb2_query_info_compound(const unsigned int xid, struct cifs_tcon *tcon,
 				resp_buftype, rsp_iov);
 	if (rc) {
 		free_rsp_buf(resp_buftype[1], rsp_iov[1].iov_base);
+		if (rc == -EREMCHG) {
+			tcon->need_reconnect = true;
+			printk_once(KERN_WARNING "server share %s deleted\n",
+				    tcon->treeName);
+		}
 		goto qic_exit;
 	}
 	*rsp = rsp_iov[1];
diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index cab696ac68ab..01d5c4af2458 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -2595,6 +2595,11 @@  SMB2_open(const unsigned int xid, struct cifs_open_parms *oparms, __le16 *path,
 		}
 		trace_smb3_open_err(xid, tcon->tid, ses->Suid,
 				    oparms->create_options, oparms->desired_access, rc);
+		if (rc == -EREMCHG) {
+			printk_once(KERN_WARNING "server share %s deleted\n",
+				    tcon->treeName);
+			tcon->need_reconnect = true;
+		}
 		goto creat_exit;
 	} else
 		trace_smb3_open_done(xid, rsp->PersistentFileId, tcon->tid,
-- 
2.20.1