chas williams - CONTRACTOR wrote:


the only objection is that this patch seems to know too much about
the behavior of the linux kernel.  interestingly enough lock_kernel()
is recursive, and AFS_GLOCK() is not.  i imagine this is what keeps
other filesystems from deadlocking in the same way.


Well, the way afs_put_inode clicks into standard kernel business is pretty much kernel-specific. It was instructive to try and understand the difference in Irix, OSF and AIX just to see that things are not always obvious (and clean).

A relatively kernel-unspecific way would be to queue an event that is handled "later" by somebody running near top level. The question is a) how to queue without a lock and b) whether sometimes things must happen "now" rather than "later". But that sounds like an added complexity with its own probability of going wrong eventually. A lot of the AFS client assumes things about the inner working of the kernel in that area so I wouldn't be too difficult about that (except for the compare for "kswapd" of course which I admit is extremely poor).

BTW: lock_kernel() is not only "recursive", it also gets dropped and reacquired when you give up control (e.g. sleep). Its semantics are quite different from the AFS global lock.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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

Reply via email to