All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Talpey <tom@talpey.com>
To: "Steve French" <smfrench@gmail.com>,
	"Aurélien Aptel" <aaptel@suse.com>,
	"Shyam Prasad N" <nspmangalore@gmail.com>
Cc: CIFS <linux-cifs@vger.kernel.org>
Subject: Re: [PATCH][SMB3] 3 small multichannel client patches
Date: Sat, 8 May 2021 09:29:13 -0400	[thread overview]
Message-ID: <98a3e99b-3d2e-0480-55db-f843c7016351@talpey.com> (raw)
In-Reply-To: <CAH2r5mu3m6FWWqrfOeQugXWGZOPiEE+Xgk8wc0rn8OgLRVPSWQ@mail.gmail.com>

On 5/7/2021 9:13 PM, Steve French wrote:
> 1) we were not setting CAP_MULTICHANNEL on negotiate request

> diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
> index e36c2a867783..a8bf43184773 100644
> --- a/fs/cifs/smb2pdu.c
> +++ b/fs/cifs/smb2pdu.c
> @@ -841,6 +841,8 @@ SMB2_negotiate(const unsigned int xid, struct cifs_ses *ses)
>  		req->SecurityMode = 0;
>  
>  	req->Capabilities = cpu_to_le32(server->vals->req_capabilities);
> +	if (ses->chan_max > 1)
> +		req->Capabilities |= cpu_to_le32(SMB2_GLOBAL_CAP_MULTI_CHANNEL);
>  
>  	/* ClientGUID must be zero for SMB2.02 dialect */
>  	if (server->vals->protocol_id == SMB20_PROT_ID)
> @@ -1032,6 +1034,9 @@ int smb3_validate_negotiate(const unsigned int xid, struct cifs_tcon *tcon)
>  
>  	pneg_inbuf->Capabilities =
>  			cpu_to_le32(server->vals->req_capabilities);
> +	if (tcon->ses->chan_max > 1)
> +		pneg_inbuf->Capabilities |= cpu_to_le32(SMB2_GLOBAL_CAP_MULTI_CHANNEL);
> +

This doesn't look quite right, and it can lead to failed negotiate by
setting CAP_MULTI_CHANNEL when the server didn't actually send the bit.
Have you tested this with servers that don't do multichannel?


> 2) we were ignoring whether the server set CAP_NEGOTIATE in the response

Is this "CAP_NEGOTIATE" a typo? I think you mean CAP_MULTI_CHANNEL.
In any case:

> diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c
> index 63d517b9f2ff..a391ca3166f3 100644
> --- a/fs/cifs/sess.c
> +++ b/fs/cifs/sess.c
> @@ -97,6 +97,12 @@ int cifs_try_adding_channels(struct cifs_sb_info *cifs_sb, struct cifs_ses *ses)
>  		return 0;
>  	}
>  
> +	if ((ses->server->capabilities & SMB2_GLOBAL_CAP_MULTI_CHANNEL) == false) {

This compares a bit to a boolean. "false" should be "0"?

> +		cifs_dbg(VFS, "server does not support CAP_MULTI_CHANNEL, multichannel disabled\n");

The wording could be clearer. Technically speaking, the server does not
support _multichannel_, which it indicated by not setting CAP_MULTI_CHANNEL.
Also, wouldn't it be more useful to add the servername to this message?
	"server %s does not support multichannel, using single channel"
or similar.


> 3) we were silently ignoring multichannel when "max_channels" was > 1
> but the user forgot to include "multichannel" in mount line.

 > diff --git a/fs/cifs/fs_context.c b/fs/cifs/fs_context.c
 > index 3bcf881c3ae9..8f7af6fcdc76 100644
 > --- a/fs/cifs/fs_context.c
 > +++ b/fs/cifs/fs_context.c
 > @@ -1021,6 +1021,9 @@ static int smb3_fs_context_parse_param(struct 
fs_context *fc,
 >  			goto cifs_parse_mount_err;
 >  		}
 >  		ctx->max_channels = result.uint_32;
 > +		/* If more than one channel requested ... they want multichan */
 > +		if ((ctx->multichannel == false) && (result.uint_32 > 1))
 > +			ctx->multichannel = true;

Wouldn't this be clearer and simpler as just "if (result.uint32 > 1)" ?

  parent reply	other threads:[~2021-05-08 13:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-08  1:13 [PATCH][SMB3] 3 small multichannel client patches Steve French
2021-05-08 12:30 ` Shyam Prasad N
2021-05-08 13:29 ` Tom Talpey [this message]
2021-05-08 15:10   ` Steve French
2021-05-08 15:20     ` Tom Talpey
2021-05-08 15:51       ` Steve French
2021-05-11 15:53 ` Aurélien Aptel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=98a3e99b-3d2e-0480-55db-f843c7016351@talpey.com \
    --to=tom@talpey.com \
    --cc=aaptel@suse.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=nspmangalore@gmail.com \
    --cc=smfrench@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.