[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANT5p=oG_btGS7xKXoRS8Z46JqBQ2E8pud9XRDWrJe1AhGaZYQ@mail.gmail.com>
Date: Tue, 23 Sep 2025 11:20:58 +0530
From: Shyam Prasad N <nspmangalore@...il.com>
To: Steve French <smfrench@...il.com>
Cc: rajasimandalos@...il.com, linux-cifs@...r.kernel.org, pc@...guebit.org,
ronniesahlberg@...il.com, sprasad@...rosoft.com, tom@...pey.com,
bharathsm@...rosoft.com, linux-kernel@...r.kernel.org,
Rajasi Mandal <rajasimandal@...rosoft.com>,
samba-technical <samba-technical@...ts.samba.org>
Subject: Re: [PATCH 1/2] cifs: client: force multichannel=off when max_channels=1
On Mon, Sep 22, 2025 at 9:36 PM Steve French <smfrench@...il.com> wrote:
>
> i just noticed a more serious problem with multichannel/max_channels
>
> When we mount with multichannel (at least to Samba e.g.) with
> multichannel disabled on the server it confusingly returns "resource
> not available" we should at least log to dmesg something more
> meaningful than what we do today:
>
> [ 1195.349188] CIFS: VFS: failed to open extra channel on
> iface:10.45.126.66 rc=-11
> [ 1195.454361] CIFS: successfully opened new channel on
> iface:2607:fb90:f2b6:0732:7504:183c:991e:6e53
> [ 1195.454599] CIFS: VFS: reconnect tcon failed rc = -11
> [ 1195.457025] CIFS: VFS: reconnect tcon failed rc = -11
> [ 1195.457040] CIFS: VFS: cifs_read_super: get root inode failed
>
>
> Samba behavior is also strange - it advertises multichannel support in
> negprot response but doesn't advertise it in session setup flags.
If the user mounts with multichannel enabled, then it is expected that
the client will try to setup more channels.
If the server cannot support it, these logs are expected.
Btw.. It looks like the client was able to setup one additional
channel above. But reconnect tcon failed. I wonder why that happened?
>
> On Mon, Sep 22, 2025 at 3:25 AM <rajasimandalos@...il.com> wrote:
> >
> > From: Rajasi Mandal <rajasimandal@...rosoft.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@...rosoft.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:
> > --
> > 2.43.0
> >
> >
>
>
> --
> Thanks,
>
> Steve
>
--
Regards,
Shyam
Powered by blists - more mailing lists