linux-kernel - Re: [PATCH] cifs: client: enforce consistent handling of multichannel and max

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAH2r5msVd2Ygtfmp_9L-tuPUMT7pcW1aQxobHuOjtgYEWRgZ6A@mail.gmail.com>
Date: Thu, 20 Nov 2025 09:04:37 -0600
From: Steve French <smfrench@...il.com>
To: Enzo Matsumiya <ematsumiya@...e.de>
Cc: Rajasi Mandal <rajasimandalos@...il.com>, Rajasi Mandal <rajasimandal@...rosoft.com>, 
	linux-cifs@...r.kernel.org, sprasad@...rosoft.com, pc@...guebit.org, 
	samba-technical@...ts.samba.org, linux-kernel@...r.kernel.org, 
	sfrench@...ba.org, bharathsm@...rosoft.com, tom@...pey.com
Subject: Re: [PATCH] cifs: client: enforce consistent handling of multichannel
 and max_channels

On Tue, Nov 18, 2025 at 8:01 AM Enzo Matsumiya via samba-technical
<samba-technical@...ts.samba.org> wrote:
>
> On 11/18, Rajasi Mandal wrote:
> >From: Rajasi Mandal <rajasimandal@...rosoft.com>
> >
> >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@...rosoft.com>
> >Signed-off-by: Rajasi Mandal <rajasimandal@...rosoft.com>
>
> 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