Re: [PATCH] cifs: client: enforce consistent handling of multichannel and max_channels

[Steve French]

On Tue, Nov 18, 2025 at 8:01 AM Enzo Matsumiya via samba-technical
<samba-technical@xxxxxxxxxxxxxxx> wrote:
>
> On 11/18, Rajasi Mandal wrote:
> >From: Rajasi Mandal <rajasimandal@xxxxxxxxxxxxx>
> >
> >Previously, the behavior of the multichannel and max_channels mount
> >options was inconsistent and order-dependent. For example, specifying
> >"multichannel,max_channels=1" would result in 2 channels, while
> >"max_channels=1,multichannel" would result in 1 channel. Additionally,
> >conflicting combinations such as "nomultichannel,max_channels=3" or
> >"multichannel,max_channels=1" did not produce errors and could lead to
> >unexpected channel counts.
> >
> >This commit introduces two new fields in smb3_fs_context to explicitly
> >track whether multichannel and max_channels were specified during
> >mount. The option parsing and validation logic is updated to ensure:
> >- The outcome is no longer dependent on the order of options.
> >- Conflicting combinations (e.g., "nomultichannel,max_channels=3" or
> >  "multichannel,max_channels=1") are detected and result in an error.
> >- The number of channels created is consistent with the specified
> >  options.
> >
> >This improves the reliability and predictability of mount option
> >handling for SMB3 multichannel support.
> >
> >Reviewed-by: Shyam Prasad N <sprasad@xxxxxxxxxxxxx>
> >Signed-off-by: Rajasi Mandal <rajasimandal@xxxxxxxxxxxxx>
>
> It's conflicting because it's already too complex for something that
> should've been simple.  This patch introduces a new field + unnecessary
> logic on top if it all.
>
> cf. a PoC patch I sent a while ago, we can (ab)use fsparam with same key
> name, but different key types, so we could only deal with:
>
> 'nomultichannel', 'multichannel={0,1,off,no}' as multichannel disabled
> 'multichannel' as ctx->max_channels=2 (multichannel enabled, obviously)
> 'multichannel=X' as ctx->max_channels=X (ditto)
>
> Makes 0 sense to have both multichannel and max_channels mount options.

We can't regress customers who use common mount options without
warning them for multiple releases that parm is going to be removed.

I don't object to changing Opt_max_channels parsing so
ctx->max_channels in fs_context fgoes rom a # to a combination of
number and something which can be mapped to on/off (for on client
picks default on the fly while for off sets channels to 1) and
removing ctx->multichannel - so if you specify "multichannel" it sets
ctx->max_channels to something like -1  (or whatever max # is) and if
you set nomultichannel it sets ctx->max_channels to 1

-- 
Thanks,

Steve