Re: [PATCH 1/2] cifs: client: force multichannel=off when max_channels=1

[Enzo Matsumiya]

On 09/23, Shyam Prasad N wrote:
> On Mon, Sep 22, 2025 at 8:29 PM Enzo Matsumiya <ematsumiya@xxxxxxx> wrote:
> > On 09/22, Henrique Carvalho wrote:
> > >Hi Rajasi,
> > >
> > >On 9/22/25 5:24 AM, rajasimandalos@xxxxxxxxx wrote:
> > >> From: Rajasi Mandal <rajasimandal@xxxxxxxxxxxxx>
> > >>
> > >> Previously, specifying both multichannel and max_channels=1 as mount
> > >> options would leave multichannel enabled, even though it is not
> > >> meaningful when only one channel is allowed. This led to confusion and
> > >> inconsistent behavior, as the client would advertise multichannel
> > >> capability but never establish secondary channels.
> > >>
> > >> Fix this by forcing multichannel to false whenever max_channels=1,
> > >> ensuring the mount configuration is consistent and matches user intent.
> > >> This prevents the client from advertising or attempting multichannel
> > >> support when it is not possible.
> > >>
> > >> Signed-off-by: Rajasi Mandal <rajasimandal@xxxxxxxxxxxxx>
> > >> ---
> > >>  fs/smb/client/fs_context.c | 7 +++++++
> > >>  1 file changed, 7 insertions(+)
> > >>
> > >> diff --git a/fs/smb/client/fs_context.c b/fs/smb/client/fs_context.c
> > >> index 072383899e81..43552b44f613 100644
> > >> --- a/fs/smb/client/fs_context.c
> > >> +++ b/fs/smb/client/fs_context.c
> > >> @@ -1820,6 +1820,13 @@ static int smb3_fs_context_parse_param(struct fs_context *fc,
> > >>              goto cifs_parse_mount_err;
> > >>      }
> > >>
> > >> +    /*
> > >> +     * Multichannel is not meaningful if max_channels is 1.
> > >> +     * Force multichannel to false to ensure consistent configuration.
> > >> +     */
> > >> +    if (ctx->multichannel && ctx->max_channels == 1)
> > >> +            ctx->multichannel = false;
> > >> +
> > >>      return 0;
> > >>
> > >>   cifs_parse_mount_err:
> > >
> > >Do we even need ->multichannel flag at all? Maybe we could replace
> > >->multichannel for a function that checks for max_channels > 1?
> >
> > I agree with Henrique.
> >
> > I'd actually like to propose going even further and having the whole
> > module behaving as if multichannel was always on, even with
> > max_channels=1 -- the only difference being the need to run the
> > query_interfaces worker.
> >
> > This is probably work for another patch/series though.
> >
> >
> > Cheers,
> >
> > Enzo
>
> Although I agree with this line of thought, I'd want to do it slightly
> differently.
> max_channels should be a configurable option for users to tune the
> number of max channels, even if the actual channel count is lower.
> multichannel mount option should be kept to maintain backward
> compatibility, but always be interpreted based on max_channels value.
>
> In the future, we should make max_channels=16 the default, thereby
> enabling multichannel by default. Users optionally can set
> max_channels to a lower value.

Have you seen the PoC patch I put here?
https://lore.kernel.org/linux-cifs/byjdlepkzmhm6j4ap5eyzdcusl7dgq3iuhkduf3s5h4mrayj32@lzwe2rksc4ei/

It's an attempt to remove confusion for the user-facing mount options.

As for behaviour, I think we all agree on it in general, it's just that
the implementation (dev perspective, having too many ways to check for
the same thing) is confusing and error prone cf. my comment about
query_interfaces worker running even if the user never requested
multichannel -- regardless if it runs every Xmin, it's 100% unnecessary.


Cheers,

Enzo