The problem is not in using dentries per se, it's in using the _dentry
pointer_ as the id. Once the dentries are confined to a SLAB cache,
there may be only a few thousand unique dentry values, so there's a very
significant chance of a client presenting a dentry that validates to the
wrong object.
Using inode numbers as nfsd filehandles works because it represents the
object itself -- a dentry pointer doesn't represent anything once you
dput it. I'm not suggesting using inode numbers as the id though -- it
would be better to use a code that incorporates a hash for efficient
lookup, and a non-repeating id to keep it unique.
I don't think it would be very hard to change the current code to
implement my proposal. Basically fh_compose would take a dentry and add
it to the hash table if it didn't already exist, and generate a unique
id number for it. fh_verify would take the id value and look up the
dentry; all of the validation would be local, as dentries in the hash
table have the use count held. The current use count tracking would
remain unchanged; file handles from fh_verify or fh_compose would still
hold a use count and have to be fh_put.
One big advantage is that nfsd could implement a rational dentry
expiration algorithm. Frequently used dentries would stay valid for a
long time, and the server could even initialize the dentry table based
on past usage patterns.
Anyway, it's just a suggestion, and maybe others have a better idea.
Regards,
Bill