| Message ID | CAH2r5mtFA5c5XxL6ohwyGqj=zPc0mUR1_VNvcMyhrZZJuwcBPA@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [SMB3] Fix share deleted and share recreated cases | expand |
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
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
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
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
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
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