| Message ID | 20230622181604.4788-1-sprasad@microsoft.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/3] cifs: log session id when a matching ses is not found | expand |
Shyam Prasad N <nspmangalore@gmail.com> writes: > We do not log the session id in crypt_setup when a matching > session is not found. Printing the session id helps debugging > here. This change does just that. > > Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> > --- > fs/smb/client/smb2ops.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c > index a8bb9d00d33a..8e4900f6cd53 100644 > --- a/fs/smb/client/smb2ops.c > +++ b/fs/smb/client/smb2ops.c > @@ -4439,8 +4439,8 @@ crypt_message(struct TCP_Server_Info *server, int num_rqst, > > rc = smb2_get_enc_key(server, le64_to_cpu(tr_hdr->SessionId), enc, key); > if (rc) { > - cifs_server_dbg(VFS, "%s: Could not get %scryption key\n", __func__, > - enc ? "en" : "de"); > + cifs_server_dbg(VFS, "%s: Could not get %scryption key. sid: 0x%llx\n", __func__, > + enc ? "en" : "de", le64_to_cpu(tr_hdr->SessionId)); I think this should be FYI rather than VFS as it is usually fine to fail on smb2_get_enc_key() while the session was reconnected, since the I/O would be retried later and the current value of @tr_hdr->SessionId would no longer match any existing session ids. I have seen such messages while running reconnect tests with 'seal' mount option. Other than that, looks good.
On Fri, Jun 23, 2023 at 12:15 AM Paulo Alcantara <pc@manguebit.com> wrote: > > Shyam Prasad N <nspmangalore@gmail.com> writes: > > > We do not log the session id in crypt_setup when a matching > > session is not found. Printing the session id helps debugging > > here. This change does just that. > > > > Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> > > --- > > fs/smb/client/smb2ops.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c > > index a8bb9d00d33a..8e4900f6cd53 100644 > > --- a/fs/smb/client/smb2ops.c > > +++ b/fs/smb/client/smb2ops.c > > @@ -4439,8 +4439,8 @@ crypt_message(struct TCP_Server_Info *server, int num_rqst, > > > > rc = smb2_get_enc_key(server, le64_to_cpu(tr_hdr->SessionId), enc, key); > > if (rc) { > > - cifs_server_dbg(VFS, "%s: Could not get %scryption key\n", __func__, > > - enc ? "en" : "de"); > > + cifs_server_dbg(VFS, "%s: Could not get %scryption key. sid: 0x%llx\n", __func__, > > + enc ? "en" : "de", le64_to_cpu(tr_hdr->SessionId)); > > I think this should be FYI rather than VFS as it is usually fine to fail > on smb2_get_enc_key() while the session was reconnected, since the I/O > would be retried later and the current value of @tr_hdr->SessionId would > no longer match any existing session ids. I have seen such messages > while running reconnect tests with 'seal' mount option. > > Other than that, looks good. Ack Paulo. I'll send an updated patch after reducing this to FYI log.
diff --git a/fs/smb/client/smb2ops.c b/fs/smb/client/smb2ops.c index a8bb9d00d33a..8e4900f6cd53 100644 --- a/fs/smb/client/smb2ops.c +++ b/fs/smb/client/smb2ops.c @@ -4439,8 +4439,8 @@ crypt_message(struct TCP_Server_Info *server, int num_rqst, rc = smb2_get_enc_key(server, le64_to_cpu(tr_hdr->SessionId), enc, key); if (rc) { - cifs_server_dbg(VFS, "%s: Could not get %scryption key\n", __func__, - enc ? "en" : "de"); + cifs_server_dbg(VFS, "%s: Could not get %scryption key. sid: 0x%llx\n", __func__, + enc ? "en" : "de", le64_to_cpu(tr_hdr->SessionId)); return rc; }
We do not log the session id in crypt_setup when a matching session is not found. Printing the session id helps debugging here. This change does just that. Signed-off-by: Shyam Prasad N <sprasad@microsoft.com> --- fs/smb/client/smb2ops.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)