Generic name to handle and open by handle syscalls

fs/open.c +5 -0

+	 * Find the vfsmount for this superblock in the
+	 * current namespace
+	 */
+	mnt = fs_get_vfsmount(current, sb);
+	if (!mnt) {

fs/open.c err_out: · line 1346

Quoted 2 lines · Aneesh Kumar K.V

fs/open.c +2 -0

+long do_sys_open_by_handle(struct file_handle *fh, int flags)
+{

Note this is inconsistent with the patch description that says that the syscall is open_by_handle_at(). While the syscall is still using the "_at()" suffix, it is no longer passing any directory.

fs/open.c err_out: · line 1361

Quoted 4 lines

fs/open.c +3 -0

+	sb = fs_get_sb(&fh->fsid);
+	if (!sb)
+		return -ESTALE;

I was going to say that it would be nice to allow a fallback to the "_at" directory of the filesystem, but since the handle is specific to the exact filesystem it was created on anyway (inode number+generation, not even an rsync would be enough) the only way the handle is useful on another node is if the filesystem was cloned at the block device level (or is a shared filesystem identical on all nodes) so the UUID should be identical too.

Quoted 10 lines

fs/open.c +10 -0

+	 * Find the vfsmount for this superblock in the
+	 * current namespace
+	 */
+	mnt = fs_get_vfsmount(current, sb);
+	if (!mnt) {
+		deactivate_super(sb);
+		return -ESTALE;
+	}
+
+	dentry = handle_to_dentry(mnt, fh);

fs/open.c err_out: · line 1377

Quoted 5 lines

fs/open.c +5 -0

+	if (IS_ERR(dentry)) {
+		mntput(mnt);
+		deactivate_super(sb);
+		return PTR_ERR(dentry);
+	}

Why is this code doing "manual" cleanup instead of setting retval and goto out_sb: or out_mnt: type labels that only do partial cleanup?

fs/open.c err_out: · line 1430

Quoted 6 lines

fs/open.c +5 -0

+	fsnotify_open(filp->f_path.dentry);
+	fd_install(fd, filp);
+	mntput(mnt);
+	deactivate_super(sb);
+	return fd;

This could set retval = fd and goto out_mnt: (skipping dput(dentry)) in conjunction with the change proposed below.

fs/open.c err_out: · line 1437

Quoted 6 lines

fs/open.c +6 -0

+err_out:
+	mntput(mnt);
+	deactivate_super(sb);
+	dput(dentry);
+	return retval;
+}

I think it makes sense to do the dput(dentry) first, since it will be holding a reference on the sb and vfsmnt, and it also allows code simplification:

out_err:

       dput(dentry);
out_mnt:
       mntput(mnt);
out_sb:
       deactivate_super(sb);

       return retval;
}

The below set of patches implement open by handle support using exportfs operations. This allows user space application to map a file name to file handle and later open the file using handle.

TODO:
I guess we would need to optimize how we get the vfsmount for the filesystem
uuid specified. Searching the file system list and task name space may be a big overhead for each open by handle call.

Chages from V2:
a) Support system wide unique handle.

Hi,

The below set of patches implement open by handle support using exportfs operations. This allows user space application to map a file name to file handle and later open the file using handle. This should be usable for userspace NFS [1] and 9P server [2]. XFS already support this with the ioctls XFS_IOC_PATH_TO_HANDLE and XFS_IOC_OPEN_BY_HANDLE.

[1] http://nfs-ganesha.sourceforge.net/
[2] http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01087.html

TODO:
I guess we would need to optimize how we get the vfsmount for the filesystem uuid specified. Searching the file system list and task name space may be a big overhead for each open by handle call.

Chages from V2:
a) Support system wide unique handle.

Changes from v1:
a) handle size is now specified in bytes
b) returns -EOVERFLOW if the handle size is small
c) dropped open_handle syscall and added open_by_handle_at syscall open_by_handle_at takes mount_fd as the directory fd of the mount point containing the file
e) handle will only be unique in a given file system. So for an NFS server exporting multiple file system, NFS server will have to internally track the mount point to which a file handle belongs to. We should be able to do it much easily than expecting kernel to give a system wide unique file handle. System wide unique file handle would need much larger changes to the exportfs or VFS interface and I was not sure whether we really need to do that in the kernel or in the user space
f) open_handle_at now only check for DAC_OVERRIDE capability

Quoted 19 lines · Aneesh Kumar K.V

Hi,

The below set of patches implement open by handle support using exportfs operations. This allows user space application to map a file name to file handle and later open the file using handle. This should be usable for userspace NFS [1] and 9P server [2]. XFS already support this with the ioctls XFS_IOC_PATH_TO_HANDLE and XFS_IOC_OPEN_BY_HANDLE.

[1] http://nfs-ganesha.sourceforge.net/
[2] http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01087.html

TODO:
I guess we would need to optimize how we get the vfsmount for the filesystem uuid specified. Searching the file system list and task name space may be a big overhead for each open by handle call.

Chages from V2:
a) Support system wide unique handle.

Quoted 14 lines

Changes from v1:
a) handle size is now specified in bytes
b) returns -EOVERFLOW if the handle size is small
c) dropped open_handle syscall and added open_by_handle_at syscall open_by_handle_at takes mount_fd as the directory fd of the mount point containing the file
e) handle will only be unique in a given file system. So for an NFS server exporting multiple file system, NFS server will have to internally track the mount point to which a file handle belongs to. We should be able to do it much easily than expecting kernel to give a system wide unique file handle. System wide unique file handle would need much larger changes to the exportfs or VFS interface and I was not sure whether we really need to do that in the kernel or in the user space
f) open_handle_at now only check for DAC_OVERRIDE capability

Hi Aneesh,

it still scares me a bit as I expect to see some privileged userspace daemon accept (forged) handles from unprivileged users and pass back open fds, but adding some random token to prevent that would require storing it, so I think you're doing what you reasonably can by requiring DAC_OVERRIDE.

nsproxy bit looks fine, and i saw no problems in the rest of the set. As Andreas was saying I don't see why you're calling it _at, but meanwhile

Acked-by Serge Hallyn <[email protected]>

to the set.

-serge

Quoted 37 lines · Serge E. Hallyn

Quoted 19 lines · Aneesh Kumar K.V

Hi,

The below set of patches implement open by handle support using exportfs operations. This allows user space application to map a file name to file handle and later open the file using handle. This should be usable for userspace NFS [1] and 9P server [2]. XFS already support this with the ioctls XFS_IOC_PATH_TO_HANDLE and XFS_IOC_OPEN_BY_HANDLE.

[1] http://nfs-ganesha.sourceforge.net/
[2] http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01087.html

TODO:
I guess we would need to optimize how we get the vfsmount for the filesystem uuid specified. Searching the file system list and task name space may be a big overhead for each open by handle call.

Chages from V2:
a) Support system wide unique handle.

Quoted 14 lines

Changes from v1:
a) handle size is now specified in bytes
b) returns -EOVERFLOW if the handle size is small
c) dropped open_handle syscall and added open_by_handle_at syscall open_by_handle_at takes mount_fd as the directory fd of the mount point containing the file
e) handle will only be unique in a given file system. So for an NFS server exporting multiple file system, NFS server will have to internally track the mount point to which a file handle belongs to. We should be able to do it much easily than expecting kernel to give a system wide unique file handle. System wide unique file handle would need much larger changes to the exportfs or VFS interface and I was not sure whether we really need to do that in the kernel or in the user space
f) open_handle_at now only check for DAC_OVERRIDE capability

Hi Aneesh,

Quoted 5 lines

it still scares me a bit as I expect to see some privileged userspace daemon accept (forged) handles from unprivileged users and pass back open fds, but adding some random token to prevent that would require storing it, so I think you're doing what you reasonably can by requiring DAC_OVERRIDE.

We still do access permission check using the file permission modes.

What we don't do is to check the execute (x) bit on the directory. But the idea of adding DAC_OVERRIDE is to make sure that we allow only privileged user to use the open by handle interface.

Quoted 5 lines

nsproxy bit looks fine, and i saw no problems in the rest of the set. As Andreas was saying I don't see why you're calling it _at, but meanwhile

Quoted 1 line

Acked-by Serge Hallyn <[email protected]>

I missed adding Acked-by: in V4 iteration. But will add in V5 iteration. Can i add the same to all the patches ? Or do you want me to add only to the nsproxy bits.

TODO:
I guess we would need to optimize how we get the vfsmount for the filesystem uuid specified. Searching the file system list and task name space may be a big overhead for each open by handle call.

Something to consider is whether anything bad happens if there are multiple filesystems mounted with the same UUID. I can think of two ways this could happen. One is when we make a read-only LVM snapshot of a filesystem, and then mount it to back up a stable snapshot. This might happen if the sysadmin is trying to backup a SQL database, for example; the database gets frozen, we take a snapshot, and then we unfreeze the database and mount the snapshot. Now suppose we try to open-by-handle the mysql database --- should the system return the a file from the r/o frozen snapshot, or from the r/w file system?

Something we might do is to add a check and refuse mounting file systems with duplicate UUID's, and changing the LVM snapshot code to do run some kind of hook after a snapshot which runs a "tune2fs -U random" on the snapshot. For r/o LVM snapshots, we could also put in a hack that if there are two file systems mounted, one r/o and one r/w, we return the r/w file system.

Quoted 2 lines · Theodore Tso

Something to consider is whether anything bad happens if there are multiple filesystems mounted with the same UUID. I can think of two ways this could happen. One is when we make a read-only LVM snapshot of a filesystem, and then mount it to back up a stable snapshot. This might happen if the sysadmin is trying to backup a SQL database, for example; the database gets frozen, we take a snapshot, and then we unfreeze the database and mount the snapshot. Now suppose we try to open-by-handle the mysql database --- should the system return the a file from the r/o frozen snapshot, or from the r/w file system?

I'd say from the r/w LV in virtually all cases. We are safe from totally egregious errors, because the inode+generation will prevent totally incorrect files from being returned, but newer/older versions of the same file/director may be found.

Quoted 1 line

Something we might do is to add a check and refuse mounting file systems with duplicate UUID's, and changing the LVM snapshot code to do run some kind of hook after a snapshot which runs a "tune2fs -U random" on the snapshot. For r/o LVM snapshots, we could also put in a hack that if there are two file systems mounted, one r/o and one r/w, we return the r/w file system.

I think this may break things if we change the UUID when a snapshot is created, because we don't know what userspace might be using the UUID for. That said, I totally agree that returning the r/w LV makes sense. The LVM code itself understands which LV is the primary and which is the snapshot, so it likely means that the "lookup the UUID" code might need to be smarter.

Probably the simplest thing is if a new filesystem is mounted, but a second filesystem with the same UUID is mounted that it is skipped. If we keep the UUID list in FIFO order, that should be sufficient to ensure that the "primary" version is returned first.

From the kernel's perspective, the only unique identifier for a file system

Quoted 4 lines · On Fri, 23 Apr 2010 18:19:59 -0600 Andreas Dilger <[email protected]> wrote:

Quoted 2 lines · Theodore Tso

Something to consider is whether anything bad happens if there are multiple filesystems mounted with the same UUID. I can think of two ways this could happen. One is when we make a read-only LVM snapshot of a filesystem, and then mount it to back up a stable snapshot. This might happen if the sysadmin is trying to backup a SQL database, for example; the database gets frozen, we take a snapshot, and then we unfreeze the database and mount the snapshot. Now suppose we try to open-by-handle the mysql database --- should the system return the a file from the r/o frozen snapshot, or from the r/w file system?

Quoted 8 lines

I'd say from the r/w LV in virtually all cases. We are safe from totally egregious errors, because the inode+generation will prevent totally incorrect files from being returned, but newer/older versions of the same file/director may be found.

Quoted 1 line

Something we might do is to add a check and refuse mounting file systems with duplicate UUID's, and changing the LVM snapshot code to do run some kind of hook after a snapshot which runs a "tune2fs -U random" on the snapshot. For r/o LVM snapshots, we could also put in a hack that if there are two file systems mounted, one r/o and one r/w, we return the r/w file system.

I think this may break things if we change the UUID when a snapshot is created, because we don't know what userspace might be using the UUID for. That said, I totally agree that returning the r/w LV makes sense. The LVM code itself understands which LV is the primary and which is the snapshot, so it likely means that the "lookup the UUID" code might need to be smarter.

Probably the simplest thing is if a new filesystem is mounted, but a second filesystem with the same UUID is mounted that it is skipped. If we keep the UUID list in FIFO order, that should be sufficient to ensure that the "primary" version is returned first.

I really think this sounds too much like 'policy'. It is not a trivially obvious algorithm for selecting the 'right' filesystem. It depends on the order things have happened, which might be right for the case that you are thinking of, but might be wrong for some other case.

I haven't been following the conversation closely so I might have missed something, but why don't we leave the mapping from handle->filesystem up to userspace and just do the "filesystem+handle -> file" part in the kernel? (i.e. just what nfsd does).

From the kernel's perspective, the only unique identifier for a file system is a (sometimes fictitious or arbitrary) device number. Using anything else (except maybe a mount point) in a kernel interface just seems wrong.

Maybe map the filesystem part of the handle from UUID (or whatever) to devno in userspace, then pass the devno+file-part-of-handle to the kernel to perform, the final mapping.

Maybe map the filesystem part of the handle from UUID (or whatever) to devno in userspace, then pass the devno+file-part-of-handle to the kernel to perform, the final mapping.

Quoted 3 lines · Neil Brown

Maybe map the filesystem part of the handle from UUID (or whatever) to devno in userspace, then pass the devno+file-part-of-handle to the kernel to perform, the final mapping.

The device number is not a useful kernel interface at all. Getting a uuid really is easy in kernelspace as it's available in the superblock for every reasonable fs. What's more difficult is finding the right vfsmount instance of a superblock to use - not just due to read only but also things like no* per-vfsmount flags.

If you look at libhandle in xfsprogs which wraps the existing xfs handle ioctls for use in application you'll see such a hash table to map to open file descriptors per filesystems due to the limits of the ioctl interface. Doing the uuid lookup in kernelspace sounds much saner as we have a list of mounts there anyway.

uuids - as Ted as shown - are not necessarily unique (despite the name), so using them to perform a lookup will either be imperfect (not good for a kernel interface) or will impose extra uniqueness which would break current configurations.

Quoted 4 lines · Neil Brown

uuids - as Ted as shown - are not necessarily unique (despite the name), so using them to perform a lookup will either be imperfect (not good for a kernel interface) or will impose extra uniqueness which would break current configurations.

UUID can easily be made unique. XFS for example refuses to mount filesystems with duplicate UUIDs.

Quoted 6 lines · On Mon, 26 Apr 2010 06:28:44 -0400 Christoph Hellwig <[email protected]> wrote:

Quoted 4 lines · Neil Brown

uuids - as Ted as shown - are not necessarily unique (despite the name), so using them to perform a lookup will either be imperfect (not good for a kernel interface) or will impose extra uniqueness which would break current configurations.

Quoted 3 lines

UUID can easily be made unique. XFS for example refuses to mount filesystems with duplicate UUIDs.

In the email from Ted that I referred to he identified two cases where UUIDs are not unique. Are you suggesting that we should cause those use-cases - which work today - to fail?

So XFS won't allow you to make a read-only snapshot of an XFS file system, and then mount it somewhere else?

Quoted 2 lines · Theodore Tso

Something to consider is whether anything bad happens if there are multiple filesystems mounted with the same UUID. I can think of two ways this could happen. One is when we make a read-only LVM snapshot of a filesystem, and then mount it to back up a stable snapshot. This might happen if the sysadmin is trying to backup a SQL database, for example; the database gets frozen, we take a snapshot, and then we unfreeze the database and mount the snapshot. Now suppose we try to open-by-handle the mysql database --- should the system return the a file from the r/o frozen snapshot, or from the r/w file system?

I'd say from the r/w LV in virtually all cases. We are safe from totally egregious errors, because the inode+generation will prevent totally incorrect files from being returned, but newer/older versions of the same file/director may be found.

Quoted 1 line

Something we might do is to add a check and refuse mounting file systems with duplicate UUID's, and changing the LVM snapshot code to do run some kind of hook after a snapshot which runs a "tune2fs -U random" on the snapshot. For r/o LVM snapshots, we could also put in a hack that if there are two file systems mounted, one r/o and one r/w, we return the r/w file system.

I think this may break things if we change the UUID when a snapshot is created, because we don't know what userspace might be using the UUID for. That said, I totally agree that returning the r/w LV makes sense. The LVM code itself understands which LV is the primary and which is the snapshot, so it likely means that the "lookup the UUID" code might need to be smarter.

Probably the simplest thing is if a new filesystem is mounted, but a second filesystem with the same UUID is mounted that it is skipped. If we keep the UUID list in FIFO order, that should be sufficient to ensure that the "primary" version is returned first.