On Apr 2, 2007, at 12:03 PM, Phil Carns wrote:
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.
Hi Phil,
Good idea to look at the other file systems. My (admittedly limited)
understanding of disconnected dentries is based on the Documentation/
filesystems/Exporting doc, which may be a bit outdated. It suggests
that lookup should return whatever d_splice_alias returns (assuming
the inode exists), which may return NULL when the dentry is
disconnected?
Also, it seems clear that ENOENT cases require returning NULL.
-sam
-Phil
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
