On Fri, Jun 23, 2023 at 12:15 AM Paulo Alcantara <pc@xxxxxxxxxxxxx> wrote:
>
> Shyam Prasad N <nspmangalore@xxxxxxxxx> 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@xxxxxxxxxxxxx>
> > ---
> > 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.
--
Regards,
Shyam
