Re: [PATCH 12/14] cifs: handle when server stops supporting multichannel

Paulo Alcantara
2023-11-09T13:28:17Z

Shyam Prasad N <nspmangalore@gmail.com> writes:

> On Thu, Nov 9, 2023 at 1:11 AM Paulo Alcantara <pc@manguebit.com> wrote:
>>
>> > and leaked server connections
>> >
>> > Display Internal CIFS Data Structures for Debugging
>> > ---------------------------------------------------
>> > CIFS Version 2.46
>> > Features: DFS,FSCACHE,STATS2,DEBUG2,ALLOW_INSECURE_LEGACY,CIFS_POSIX,UPCALL(SPNEGO),XATTR,ACL,WITNESS
>> > CIFSMaxBufSize: 16384
>> > Active VFS Requests: 0
>> >
>> > Servers:
>> > 1) ConnectionId: 0x70e Hostname: w22-root2.gandalf.test
>> > ClientGUID: 44DAE383-3E91-3042-85FE-87D6F17298B7
>> > Number of credits: 1,1,1 Dialect 0x210
>> > Server capabilities: 0x300007
>> > TCP status: 4 Instance: 77
>> > Local Users To Server: 1 SecMode: 0x1 Req On Wire: 0 Net namespace: 4026531840
>> > In Send: 0 In MaxReq Wait: 0
>> > DFS leaf full path: \\W22-ROOT1.GANDALF.TEST\dfstest3\link10
>> >
>> > Sessions:
>> > [NONE]
>> > 2) ConnectionId: 0x706 Hostname: w22-root2.gandalf.test
>> > ClientGUID: C8CF45E4-F70D-DF40-8821-0234A2E20DD4
>> > Number of credits: 1,1,1 Dialect 0x210
>> > Server capabilities: 0x300007
>> > TCP status: 4 Instance: 81
>> > Local Users To Server: 1 SecMode: 0x1 Req On Wire: 0 Net namespace: 4026531840
>> > In Send: 0 In MaxReq Wait: 0
>> > DFS leaf full path: \\W22-ROOT1.GANDALF.TEST\dfstest3\link6
>> >
>> > Sessions:
>> > [NONE]
>> > 3) ConnectionId: 0x6ae Hostname: w22-root1.gandalf.test
>> > ClientGUID: AB059CDD-12FF-B94D-B30C-9E1928ACBA95
>> > Number of credits: 1,1,1 Dialect 0x210
>> > Server capabilities: 0x300007
>> > TCP status: 4 Instance: 96
>> > Local Users To Server: 1 SecMode: 0x1 Req On Wire: 0 Net namespace: 4026531840
>> > In Send: 0 In MaxReq Wait: 0
>> > DFS leaf full path: \\W22-ROOT1.GANDALF.TEST\dfstest3\link9
>> >
>> > Sessions:
>> > [NONE]
>> > ...
>>
>> I ended up with a simple reproducer for the above
>>
>> mount.cifs //srv/share /mnt/1 -o ...,echo_interval=10
>> iptables -I INPUT -s $srvaddr -j DROP
>> stat -f /mnt/1
>> # check dmesg for "BUG: sleeping function called from invalid context"
>> iptables -I INPUT -s $srvaddr -j ACCEPT
>> stat -f /mnt/1
>> umount /mnt/1
>> # check /proc/fs/cifs/DebugData for leaked server connection
>
> Ack. I'll try and get a repro locally and debug this one.

This should be related to patch 10/14 as you're taking an extra
reference of @server over reconnect, and when the client reconnects and
umount, that reference don't seem to be put afterwards.