It looks like if a non-null dentry is returned from lookup, dput is
called on that dentry, which decrements the usage count. If null is
returned dput isn't called. Could it be that we're actually leaking
entries in the dcache with these patches?
-sam
Maybe? I'm not sure what's supposed to happen here. Just doing a very
quick survey, for example:
2.4.28: ext3_lookup() always returns NULL on success
2.4.28: nfs_lookup() always returns NULL on success
2.4.28: smb_lookup() always returns NULL on success
2.6.20: ext3_lookup() relies on d_splice_alias to determine non-error
return codes. Returns NULL for some cases, but not all.
2.6.20: nfs_lookup() relies on d_materialize_unique to indirectly
determine non-error return codes. Returns NULL for some cases, but not all.
2.6.20: smb_lookup() always returns NULL on success
So by rather dubious "what is everyone else doing?" methodology, it
would seem that on 2.4 we can always return NULL, but on 2.6 we need to
figure out why some file systems sometimes don't return NULL and see if
it applies to PVFS2? It doesn't seem as cut and dry as always doing one
or the other on 2.6 - maybe there is a little more going on here.
-Phil
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
