[Pvfs2-developers] patch: namei bug fixes

[Sam Lang]

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
>