Christoph Hellwig <hch@xxxxxxxxxxxxx> writes:
> On Fri, May 02, 2008 at 11:55:37AM +1000, xaiki@xxxxxxx wrote:
>> One of our DMAPI user found that in some cases inodes weren't getting through
>> xfs_inactive() in any reasonable amount of time. Investigation tracked it
>> down
>> to the use of d_alloc_anon() combined with another thread accessing the same
>> inode via an open().
>>
>> So we introduce a stripped down version of d_alloc_anon, that won't try to
>> find
>> an existing dentry, nor will hash it.
>
> No, this is even more buggy than using d_alloc_anon.
I must be missing a point here, can you please further explain why is it
buggy ? We are indeed abusing the normal dentry life, but that's what we
want libhandle to be. i.e. We really don't need it connected, we don't
need to know anything about that file, we just want to access it.
> What really needs to be done in the handle code is to do the full
> reconnect logic nfsd would be doing.
That would be slow, and we don't really need it. What is wrong with
having a temp hanging dentry if it gets thorn appart properly ? The
dentry we're using never makes it to any kind of cache. We don't even
have security concerns as the 2 pieces of code can only be triggered by
root.
> Aka you should be using exportfs_decode_fh and update xfs's
> fh_to_dentry method to accept the file handle type used by the handle
> interface.
Cheers,
--
Niv Sardi
|