* [SMB3][PATCH] Fix share deleted and share recreated cases
@ 2019-09-11 5:13 Steve French
2019-09-11 5:24 ` ronnie sahlberg
0 siblings, 1 reply; 6+ messages in thread
From: Steve French @ 2019-09-11 5:13 UTC (permalink / raw)
To: CIFS
[-- Attachment #1: Type: text/plain, Size: 712 bytes --]
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
[-- Attachment #2: 0001-smb3-improve-handling-of-share-deleted-and-share-rec.patch --]
[-- Type: text/x-patch, Size: 4053 bytes --]
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
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [SMB3][PATCH] Fix share deleted and share recreated cases
2019-09-11 5:13 [SMB3][PATCH] Fix share deleted and share recreated cases Steve French
@ 2019-09-11 5:24 ` ronnie sahlberg
2019-09-11 17:08 ` Pavel Shilovsky
0 siblings, 1 reply; 6+ messages in thread
From: ronnie sahlberg @ 2019-09-11 5:24 UTC (permalink / raw)
To: Steve French; +Cc: CIFS
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [SMB3][PATCH] Fix share deleted and share recreated cases
2019-09-11 5:24 ` ronnie sahlberg
@ 2019-09-11 17:08 ` Pavel Shilovsky
2019-09-11 22:10 ` ronnie sahlberg
0 siblings, 1 reply; 6+ messages in thread
From: Pavel Shilovsky @ 2019-09-11 17:08 UTC (permalink / raw)
To: ronnie sahlberg; +Cc: Steve French, CIFS
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [SMB3][PATCH] Fix share deleted and share recreated cases
2019-09-11 17:08 ` Pavel Shilovsky
@ 2019-09-11 22:10 ` ronnie sahlberg
2019-09-12 17:01 ` Pavel Shilovsky
0 siblings, 1 reply; 6+ messages in thread
From: ronnie sahlberg @ 2019-09-11 22:10 UTC (permalink / raw)
To: Pavel Shilovsky; +Cc: Steve French, CIFS
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [SMB3][PATCH] Fix share deleted and share recreated cases
2019-09-11 22:10 ` ronnie sahlberg
@ 2019-09-12 17:01 ` Pavel Shilovsky
2019-09-13 0:50 ` Steve French
0 siblings, 1 reply; 6+ messages in thread
From: Pavel Shilovsky @ 2019-09-12 17:01 UTC (permalink / raw)
To: ronnie sahlberg; +Cc: Steve French, CIFS
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [SMB3][PATCH] Fix share deleted and share recreated cases
2019-09-12 17:01 ` Pavel Shilovsky
@ 2019-09-13 0:50 ` Steve French
0 siblings, 0 replies; 6+ messages in thread
From: Steve French @ 2019-09-13 0:50 UTC (permalink / raw)
To: Pavel Shilovsky; +Cc: ronnie sahlberg, CIFS
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
--
Thanks,
Steve
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-09-13 0:50 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-11 5:13 [SMB3][PATCH] Fix share deleted and share recreated cases Steve French
2019-09-11 5:24 ` ronnie sahlberg
2019-09-11 17:08 ` Pavel Shilovsky
2019-09-11 22:10 ` ronnie sahlberg
2019-09-12 17:01 ` Pavel Shilovsky
2019-09-13 0:50 ` Steve French
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).