Re: [PATCH -V7 3/9] vfs: Add name to file handle conversion support

[Aneesh Kumar K. V]

On Thu, 13 May 2010 19:51:23 +0530, "Aneesh Kumar K. V" <aneesh.kumar@xxxxxxxxxxxxxxxxxx> wrote:
> On Thu, 13 May 2010 02:30:46 -0600, Andreas Dilger <andreas.dilger@xxxxxxxxxx> wrote:
> > On 2010-05-13, at 01:11, Neil Brown wrote:
> > > Here is my reason (well, one of my reasons) why UUID is clearly not an
> > > acceptable handle to use - you *must* use an fd or are worst a path name.
> > > 
> > > A filesystem can be mounted at multiple places in the namespace and each
> > > instance can have other filesystems mounted on different directories.
> > > Each of these is a 'vfsmnt'.
> > > You need a vfsmnt for most (all?) filesystem operations.
> > > A UUID does not uniquely identify a vfsmnt.  It might uniquely identify a
> > > filesystem, though that is debatable.  It definitely does not uniquely
> > > identify a vfsmnt.
> > > Therefore, given only a UUID the kernel would have to arbitrarily choose a
> > > vfsmnt that references to the right filesystem.  If a particular directory in
> > > the filesystem that you want to access was mounted-on in that vfsmnt, that
> > > directory would be completely inaccessible to you, even though it might be
> > > completely accessible in some other vfsmnt.
> > > So it is quite possible for a scheme based on kernel interpretation of uuids
> > > to fail.
> > 
> > I think this is exactly the wrong solution for this case.  The lookup from pathname to handle happened ALREADY (in the presence of the right namespace and vfsmnt information) and all that should be required for the handle lookup is to get the exact same inode back from disk.  It is irrelevant what vfsmnt is used to do this lookup, so long as it is in the same filesystem as before.
> > 
> > > This may be a corner case, but I think people are slowly getting more
> > > adventurous in terms of using the mount table to do interesting things.  It
> > > may be less of a corner case in 5 years.
> > 
> > I think the important feature for the handle is that _regardless_ of what shenanigans are done with the path, over-mounting of directories, etc, that the same inode is returned.  One would expect that if a real fd was opened by a process, that any later changes to the namespace would not suddenly result in another file with the same pathname to be accessible by that fd.
> > 
> > > So to tell the kernel which filesystem is of interest for filehandle
> > > lookup, you *must* give it a name, whether a textual path, or a filehandle
> > > obtained by opening a textual path.
> > 
> > No, that is done at the time of open() (or in this case name_to_handle()) and afterward the name/path/vfsmnt is completely irrelevant to the fd/handle.
> 
> 
> I guess we also have the problem with readonly bind mounts.  May be we
> should use the mountdir fd and leave the fsid to mountdir fd mapping to
> userspace. 
> 
> NOTE: With the current patchset a name_to_handle on the readonly mount
> point will fail because of the new checks i added in the syscall. But in
> general i guess we need to make sure that an open_by_handle should
> follow these vfsmount flags also. 
> 
> Christoph, Andreas,
> 
> Can we agree on the use of mountdir fd ? If so i can redo the patch
> using mountdirfd.
> 

Or

How about below interface

sys_open_by_handle_at(int mountdirfd, struct file_handle *handle, int
flags)

if mountdirfd == 0
   use UUID specified in the file handle to lookup vfsmount
else
   else use mountdirfd to get the vfsmount


-aneesh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/