Re: [PATCH] cifs: Fix reacquisition of volume cookie on still-live connection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/17/2024 10:38 AM, David Howells wrote:
Paulo Alcantara <pc@xxxxxxxxxxxxx> wrote:

Consider the following example where a tcon is reused from different
CIFS superblocks:

   mount.cifs //srv/share /mnt/1 -o ${opts} # new super, new tcon
   mount.cifs //srv/share/dir /mnt/2 -o ${opts} # new super, reused tcon

So, /mnt/1/dir/foo and /mnt/2/foo will lead to different inodes.

The two mounts are accessing the same tcon (\\srv\share) but the new
superblock was created because the prefix path "\dir" didn't match in
cifs_match_super().  Trust me, that's a very common scenario.

Why does it need to lead to a different superblock, assuming ${opts} is the

The tcon is a property of the SMB3 session, it's not shared nor is
it necessarily created at mount time.

Tom.

same in both cases?  Can we not do as NFS does and share the superblock,
walking during the mount process through the directory prefix to the root
object?

In other words, why does:

     mount.cifs //srv/share /mnt/1 -o ${opts}
     mount.cifs //srv/share/dir /mnt/2 -o ${opts}

give you a different result to:

     mount.cifs //srv/share /mnt/1 -o ${opts}
     mount --bind /mnt/1/dir /mnt/2

David







[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux