[K42-discussion] DirLinuxFSVolatile deadlock

[Patrick Bozeman]

The remove function with signature

/* virtual */ SysStatus
DentryListHash::remove(char *name, uval len, NameHolderInfo *nhi /* = 
NULL */)

performs similar code but performs a delete of the HashEntry on line 280 
directly after the bucket remove.  There is indeed a delete that is 
performed for the bucket remove in simple hash, but it is for the simple 
hash's node.  It does not delete the 'datum' member inside 
HashSimpleNode, which contains the DentryListHash's HashEntry allocated 
in DentryListHash::updateOrAdd.  It seems to me that the version of 
DentryListHash::remove that takes a name and len is the correct way to 
deallocate the HashEntry, i.e. perform both the bucket remove as well as 
the delete HashEntry.

As for the other issue in this thread, I'll get some more info on the 
locks to you.  You may be right about which locks are being aquired, but 
I am definitly seeing deadlock here.  I'll collect more info on the 
locks in deadlock that occurs at the backtrace I provided.

Dilma DaSilva wrote:
>
>  > On a related note, it seems that children.remove(ObjRef, NameHolderInfo) is
>  > leaking memory.  In DentryListHash::remove(name, len, nhi) the hash
>  > entry is deleted at the end, but in DentryListHash::remove(ref, nhi) it 
>  > is not.
>
> I'm looking at DentryList.C (version 1.21), and I see that
> DentryListHash::remove(ref,nhi) is deleting the entry in line 337,
> at the point where the entry is found.  
>
>