Received-SPF: pass (google.com: domain of linux-kernel+bounces-149255-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <59c322dc49c3cc76a4b6a2de35106c61@manguebit.com>
From: Paulo Alcantara <pc@manguebit.com>
To: David Howells <dhowells@redhat.com>
Cc: dhowells@redhat.com, Steve French <sfrench@samba.org>, Shyam Prasad N
 <sprasad@microsoft.com>, linux-cifs@vger.kernel.org,
 linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cifs: Fix reacquisition of volume cookie on still-live
 connection
In-Reply-To: <277920.1713364693@warthog.procyon.org.uk>
References: <1a94a15e6863d3844f0bcb58b7b1e17a@manguebit.com>
 <14e66691a65e3d05d3d8d50e74dfb366@manguebit.com>
 <3756406.1712244064@warthog.procyon.org.uk>
 <2713340.1713286722@warthog.procyon.org.uk>
 <277920.1713364693@warthog.procyon.org.uk>
Date: Wed, 17 Apr 2024 18:25:19 -0300
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

David Howells <dhowells@redhat.com> writes:

> Paulo Alcantara <pc@manguebit.com> 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
> 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?

I don't know why it was designed that way, but the reason we have two
different superblocks with ${opts} being the same is because cifs.ko
relies on the value of cifs_sb_info::prepath to build paths out of
dentries.  See build_path_from_dentry().  So, when you access
/mnt/2/foo, cifs.ko will build a path like '[optional tree name prefix]
+ cifs_sb_info::prepath + \foo' and then reuse connections
(server+session+tcon) from first superblock to perform I/O on that file.

> 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

Honestly, I don't know how bind works at VFS level.  I see that the new
superblock isn't created and when I access /mnt/2/foo,
build_path_from_dentry() correctly returns '\dir\foo'.