Shyam Prasad N <nspmangalore@xxxxxxxxx> writes: > On Wed, Feb 28, 2024 at 2:52 PM Jan Čermák <sairon@xxxxxxxxx> wrote: >> >> Hi Shyam, >> > > Hi Jan, > Apologies for the delay. > >> On 27. 02. 24 17:17, Shyam Prasad N wrote: >> > These messages (in theory) should not show up if either multichannel >> > or max_channels are not specified mount options. >> >> That shouldn't be the case here, I checked with the user and he's not >> doing anything fishy himself (like interfering with the standard mount >> utilities), and the userspace tools creating the mounts should not be >> setting any of these options, which I confirmed by asking for his mounts >> list: >> >> //192.168.1.12/folder on /mnt/data/supervisor/mounts/folder type cifs >> (rw,relatime,vers=default,cache=strict,username=user,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.12,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1) >> //192.168.1.12/folder on /mnt/data/supervisor/media/folder type cifs >> (rw,relatime,vers=default,cache=strict,username=user,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.1.12,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1,closetimeo=1) > > Hmmm.. That seems like a bug. Yes. I see a couple of issues here: (1) cifs_chan_update_iface() seems to be called over reconnect for all dialect versions and servers that do not support FSCTL_QUERY_NETWORK_INTERFACE_INFO, so @ses->iface_count will be zero in some cases and then VFS message will start being flooded on dmesg. (2) __cifs_reconnect() is queueing smb2_reconnect_server() even for SMB1 mounts, so smb2_reconnect() ends up being called and then call SMB3_request_interfaces() because SMB2_GLOBAL_CAP_MULTI_CHANNEL is mixed with CAP_LARGE_FILES.
