[OpenAFS-devel] Delta put-inode-speedup-20050815 (Linux) ... is this correct?

[chas williams - CONTRACTOR]

In message <437880CC.6070008@pclella.cern.ch>,Rainer Toebbicke writes:
>the inode reference count is now checked to be 2 without any lock - what 
>if it is 3 and another CPU is simultaneously asking the same question? 
>In both cases afs_InactiveVCache() won't be called from either CPU.

yes, this could be a problem.  i was trying to be clever and avoid
grabbing AFS_GLOCK() everytime.  too clever maybe.  i think i was
under the impression that the inode_lock was protecting this bit.

>(The answer might be that this can't happen because of some higher level 
>lock, but I fail to see which one).

its safe to use AFS_GLOCK() but not to lock cache entry itself.
afs_put_inode() might be called while the afs_xvcache is being held.
see afs/DOC/afs_rwlocks.

>Now, as the outcome of the test is strictly speaking irrelevant what 
>would happen if the afs_InactiveVCache() call were dropped altogether?
>Or, more realistically, leaving the delta as it is and thus allowing for
>"forgotten" vcache entries, shouldn't there be some periodic scanning? I
>didn't find any explicit one.

i guess you could call afs_InactiveVCache() when you decided to recycle
linux inodes in afs_NewVCache().  afs_NewVCache() does the explicit
scanning for unused inodes.  i suspect afs_InactiveVCache() is still
necessary to handle afs_InvalidateAllSegments() and afs_remunlink().

>[ well, except the prune_dcache scan about to be convicted of 
>deadlocking when somebody holding the global lock triggers a memory 
>shortage, waits for kswapd who deadlocks on 
>prune_dcache->afs_dentry_iput->AFS_GLOCK() ].

again, this was mostly to handle active, unlinked file.  if the 
dentry is able to go away though, the associated file should
no longer have any references?  it could be the reference counting
you mention above.