Received-SPF: pass (google.com: domain of linux-kernel+bounces-150190-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
	Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
	Kingdom.
	Registered in England and Wales under Company Registration No. 3798903
From: David Howells <dhowells@redhat.com>
In-Reply-To: <59c322dc49c3cc76a4b6a2de35106c61@manguebit.com>
References: <59c322dc49c3cc76a4b6a2de35106c61@manguebit.com> <1a94a15e6863d3844f0bcb58b7b1e17a@manguebit.com> <14e66691a65e3d05d3d8d50e74dfb366@manguebit.com> <3756406.1712244064@warthog.procyon.org.uk> <2713340.1713286722@warthog.procyon.org.uk> <277920.1713364693@warthog.procyon.org.uk>
To: Paulo Alcantara <pc@manguebit.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
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <564519.1713447839.1@warthog.procyon.org.uk>
Date: Thu, 18 Apr 2024 14:43:59 +0100
Message-ID: <564520.1713447839@warthog.procyon.org.uk>

Paulo Alcantara <pc@manguebit.com> wrote:

> 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.

Yep.  You don't *need* prepath.  You could always build from the sb->s_root
without a prepath and have mnt->mnt_root offset the place the VFS thinks you
are:

	[rootdir]/	<--- s_root points here
	|
	v
	foo/
	|
	v
	bar/		<--- mnt_root points here
	|
	v
	a

Without prepath, you build back up the tree { a, bar/, foo/, [rootdir] } with
prepath you insert the prepath at the end.

Bind mounts just make the VFS think it's starting midway down, but you build
up back to s_root.

Think of a mount as just referring to a subtree of the tree inside the
superblock.  The prepath is just an optimisation - but possibly one that makes
sense for cifs if you're having to do pathname fabrication a lot.

David