Re: [PATCH V3] smb: client: Fix mount deadlock by avoiding super block iteration in DFS reconnect

[Wang Zhaolong]

> $ ./scripts/faddr2line --list fs/smb/client/cifs.o cifs_tree_connect+0x23c
> cifs_tree_connect+0x23c/0xc10:
>
> CIFS_SB at /home/pc/g/linux/fs/smb/client/cifsglob.h:1624
>   1619   }
>   1620
>   1621   static inline struct cifs_sb_info *
>   1622   CIFS_SB(struct super_block *sb)
>   1623   {
> > 1624<          return sb->s_fs_info;
>   1625   }
>   1626
>   1627   static inline struct cifs_sb_info *
>   1628   CIFS_FILE_SB(struct file *file)
>   1629   {
>
> (inlined by) cifs_tree_connect at /home/pc/g/linux/fs/smb/client/dfs.c:435
>   430                    goto out;
>   431            }
>   432
>   433            sb = cifs_get_dfs_tcon_super(tcon);
>   434            if (!IS_ERR(sb))
> > 435<                   cifs_sb = CIFS_SB(sb);
>   436
>   437            /* Tree connect to last share in @tcon->tree_name if no DFS referral */
>   438            if (!server->leaf_fullpath ||
>   439                dfs_cache_noreq_find(server->leaf_fullpath + 1, &ref, &tl)) {
>   440                    rc = ops->tree_connect(xid, tcon->ses, tcon->tree_name,
>
> You can reproduce with the following:
>
> $ kinit administrator@xxxxxxxxxx
> $ su testuser -c 'kinit administrator@xxxxxxxxxx'
> $ mount.cifs //w22-dc1.zelda.test/dfstest/link2 /mnt/1 -o sec=krb5,multiuser,echo_interval=10
> $ mount -t cifs
> //w22-dc1.zelda.test/dfstest/link2 on /mnt/1 type cifs (rw,relatime,vers=3.1.1,sec=krb5,cruid=0,cache=strict,upcall_target=app,multiuser,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.124.33,file_mode=0755,dir_mode=0755,soft,nounix,mapposix,noperm,reparse=nfs,nativesocket,symlink=native,rsize=4194304,wsize=4194304,bsize=1048576,retrans=1,echo_interval=10,actimeo=1,closetimeo=1)
> $ su testuser -c 'ls /mnt/1'
> dir1  dir10  dir3  dir5  dir6  dir8  dir9  target1_file.txt  tsub
> # disconnect target server 192.168.124.33 and then wait for oops...
>
> The problem seems related to the tcon created for testuser not having a
> link to the CIFS superblock, hence the oops when reconnecting the tcon.
>
> Could you please verify?  Thanks.


Thanks for your detailed feedback and for pointing out the issue

In my current implementation, I assumed that sb->s_fs_info was already
initialized during this process, which led to the issue. I will carefully
address this problem and ensure the link to the CIFS superblock is properly
established. I'll revise the patch accordingly and send out a V4 version as
soon as possible.

Thanks again for your review and support!

Best regards,
Wang Zhaolong