[PATCH review 6/6] vfs: Cache the results of path_connected
Eric W. Biederman
ebiederm at xmission.com
Wed Aug 5 16:28:55 UTC 2015
"J. Bruce Fields" <bfields at fieldses.org> writes:
> On Tue, Aug 04, 2015 at 05:58:59PM -0500, Eric W. Biederman wrote:
>> No problem. The basic question is: can 2Billion renames be performed on
>> the same filesystem in less time than a single path lookup? Allowing
>> the use of a 32bit counter.
> Certainly if you have control over an NFS or FUSE server then you can
> arrange for that to happen--just delay the lookup until you've processed
> enough renames. I don't know if that's interesting....
Not particularly when the whole point is to start with a bind mount, do
something trick and then have access to the whole filesystem instead of
just the part of the filesystem exposed by the bind mount.
If you control the filesystem you already have access to the entire
filesystem, so you don't need to do something trick.
That something tricky is a well placed rename that borks the tree
structure and causes .. to never see the subdirectory that is the root
of the bind mount.
>> If you could look up thread and tell me what you think of the issue with
>> file handle to dentry conversion and bind mounts I would be appreciate.
> OK, I see your comments in "[PATCH review 0/6] Bind mount escape fixes",
> I'm not sure I understand yet, I'll take a closer look.
The file handle reconstitution code can certainly be affected by all of
this. Given that it is an failure if reconnect_path can't reconnect the
path of a file handle. I think it can reasonably considered an error in
all cases if that path is outside of an exported bind mount, but I don't
know that area particularly well. The solution might just be don't
export file handles from bind mounts.
More information about the Containers