On Fri, 14 May 2010 19:40:44 +0100, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > On Fri, May 14, 2010 at 11:48:24PM +0530, Aneesh Kumar K. V wrote: > > > How about > > sys_open_by_handle(int mountdirfd, > > struct file_handle __user *ufh, int open_flag) > > > > and we validate the UUID present in the file_handle by using mountdirfd > > vfsmount. In otherwords we drop the UUID based vfsmount lookup, But > > still add UUID as a part of file handle ? > > IDGI. If you have decided upon the mountdirfd, why bother with rechecking? > You still need to handle the case when fs tells you to take a hike because > fileid was invalid. What does duplicate uuid check in the kernel buy you? We need to have a file system identifier to identify a file system with respect to which file_id need to be decoded. We can either do it in userspace via statfs or any other encoding or let the kernel fill the field for userspace. Now having kernel providing both file_id and file system id implies we can get an 'unique' handle with one syscall. (Not unique if we have multiple file system with same UUID. Userspace file server can find out whether all the mount point it is exporting have a unique UUID during startup.) Now if we have UUID as a part of file handle, adding the check make sure that we are passing the right file handle with the correct mountdirfd. If they don't match return -ESTALE. Adding UUID as a part of file handle also help us to get a 16 byte UUID of the file system in userspace in a simple syscall interface, rather than using file system specific libraries like libext2fs. -aneesh -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
