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.
