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

[Rainer Toebbicke]

Unless I am missing something essential, this delta (against 
afs/LINUX/osi_vfsops.c) can't possibly be correct:

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

The original code surrounded the test with a GLOCK which at least which
covers this particular scenario, but of course not the variant "count ==
3, CPU A glocks, tests for count==2, unlocks, CPU B locks, tests for
count==2, CPU A decrements, CPU B unlocks with the wrong conclusion".

The old code also obtained a (R) lock on the vnode, not that I believed
this would help anything in this case because AFS_FAST_RELE is called
without a lock.

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.

[ 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() ].

Any hint appreciated - I actually bumped into this delta trying to solve 
the abovementioned kswapd/prune_dcache problem and the solution looks 
too easy to work.



-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rainer Toebbicke
European Laboratory for Particle Physics(CERN) - Geneva, Switzerland
Phone: +41 22 767 8985       Fax: +41 22 767 7155