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

[Henrique Carvalho <henrique.carvalho@suse.com>]

On 9/22/25 1:14 PM, Steve French wrote:
> . >Do we even need ->multichannel flag at all?
> 
> Yes - especially in the future.   The goal is for the user to have
> three options:
> 1) (preferred) "multichannel" (max channels will be dynamically
> selected and can change) the client gets to choose how many channels
> to connect to based on what it sees in the output of the most recent
> query interfaces call (it can change on the fly as server dynamically
> adds and removes channels or networks become temporarily unreachable)

I'm guessing this would be required while we are transitioning from
setting channels dynamically to having multichannel on by default, as
you commented below. Because once we have it on by default, I don't
think there is a point in having the flag.

> 2) "max_channels="   This is for the case where user wants to choose
> the number of channels rather than have the client automatically
> (hopefully soon in the future) choose it for you
> 3) if server has mchan bugs, allow client to mount with no
> multichannel (or equivalent max_channels=1)
> 
> But ... "remount" also has to work for the three above (and currently
> doesn't) and this is what I am hoping the recent patches can fix (?)
> but haven't tested them enough yet
> 

Yes, I agree the patches are important, I am also testing them here.

> On Mon, Sep 22, 2025 at 9:59 AM Enzo Matsumiya <ematsumiya@suse.de> wrote:
>> 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
> 
> Obviously the goal (would love patches for this) is to turn
> multichannel on by default, have the client select the appropriate
> number of channels by default etc. but we have to let the user
> override it (as described above)
> 
>>
>> On 09/22, Henrique Carvalho wrote:
>>> Hi Rajasi,
>>>
>>> On 9/22/25 5:24 AM, rajasimandalos@gmail.com wrote:
>>>> From: Rajasi Mandal <rajasimandal@microsoft.com>
>>>>
>>>> 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@microsoft.com>
>>>> ---
>>>>  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
>>
> 
> 

-- 
Henrique
SUSE Labs