On Sun, 7 May 2000, Trond Myklebust wrote:
> We consider the file handle to be the equivalent of a dentry rather
> than an inode, since you are permitted by the RFCs to have several
> inequvalent file handles that correspond to the same inode
> number.
What is the permissable means in the context of NFS to determine if two
filehandles point to the same object? I'm starting to think that a
cleaner means of implementing NFS on top of address spaces would be to
make NFS return an address_spaces per (filehandle, credential) pair, then
rip struct file out of all address_space_operations and add a
findpage/getpage operation that would allow NFS to return a page in a
different address space -- having a call to perform "mapping" could be
useful for stacking or as a means to implement swap spaces (so that IO
can be done on the page directly to the underlying file).
I wouldn't care about this if the struct file * was available everywhere,
but it just isn't needed and it throws up huge obstacles in the way of
making certain optimizations in the mm layer (having struct file * in
vma's doesn't make much sense to have to traverse the
file->dentry->inode->address_space chain just to check if the page is
cached, when all vm uses can be cleanly solve with an address_space
pointer sans file), and metadata caching (page_cache_read needs a struct
file * -- something that's not fun to create when you really just want to
pass in an address_space -- of course it can be worked around by
implementing it again, but shouldn't simple code be reusable?).
> Indeed knfsd file handles are designed like this to allow the
> server to check that the user has the required permissions on the full
> path (rather than just checking on the file). This is BTW going to
> give us grief under NFS when we try to implement NFS3PROC_ACCESS for
> inode->i_ops->permission().
Per-filesystem fhandle_to_dentry! Let unix like filesystems get clean and
efficient handling trivially, and things like FAT can surely figure out a
decent filehandle by stuffing the directory cluster & filename in. Don't
go about trying to solve all the security problems with NFS -- these are
known holes that everyone is able to live with.
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:12 EST