Could we please back off the merging of these particular patches,
in order to give time for some critical debate?
I'm glad Frank has been working on this, but if there has been a
proper debate on the merits of these patches, then I must have missed
it. I have indeed seen the patches pass through my inbox once, but I
have not had time yet to review them properly, and feed back my
comments to Frank.
I have clear doubts about this patch.
The 'fake root' inode does not appear to have a well defined
behaviour when it tries to circumvent revalidation rules. AFAICS
things like 'stat()', etc will at times tend to give odd results even
if the user does have the correct credentials.
On a similar vein, I'm also unconvinced that there exist no races
between the lookup of new files, and the first setting of the
NFS_FILEID() on the root directory. fileid=1 is *not* a reserved inode
number under NFS v2 or v3, so it is perfectly legitimate for the
server to have other inodes with that number. In this case,
iget5_locked() may end up assigning the same inode to the root inode +
some other file.
I also have questions about smaller issues, such as why we need a
full second RPC client in the superblock just in order to (very
temporarily) add a second authentication flavour.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:31 EST