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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
