> On Oct 24, 2022, at 9:01 PM, NeilBrown <neilb@xxxxxxx> wrote:
>
> On Tue, 25 Oct 2022, Chuck Lever III wrote:
>>
>>> On Oct 24, 2022, at 7:43 PM, NeilBrown <neilb@xxxxxxx> wrote:
>>
>>>> + list = rhltable_lookup(&nfs4_file_rhltable, fhp,
>>>> + nfs4_file_rhash_params);
>>>> + rhl_for_each_entry_rcu(fi, tmp, list, fi_rlist) {
>>>> if (fh_match(&fi->fi_fhandle, &fhp->fh_handle)) {
>>>> if (refcount_inc_not_zero(&fi->fi_ref))
>>>> ret = fi;
>>>> } else if (d_inode(fhp->fh_dentry) == fi->fi_inode)
>>>> fi->fi_aliased = alias_found = true;
>>>
>>> This d_inde)( == fi->fi_inode test is no longer relevant. Everything in
>>> the list must have the same inode. Best remove it.
>>
>> My understanding is that more than one inode can hash into one of
>> these bucket lists. I don't see how rhltable_insert() can prevent
>> that from happening, and that will certainly be true if we go back
>> to using a fixed-size table.
>
> With rhltable each bucket is a list of lists. An rhlist_head contains
> two pointers. "rhead.next" points to the next entry in the bucket which
> will have a different key (different inode in this case). "next" points
> to the next entry with the same key - different filehandle, same inode,
> in this case.
That's the detail I didn't yet have, thanks. I will remove the extra
inode test and give it a try.
> The list you get back from rhltable_lookup() isn't the full bucket list.
> It is just the list within the bucket of all elements with the same key.
--
Chuck Lever
