This came upon a NetBSD discussion.
I had always assumed that when a mutex was initialized with an
iblock_cookie_t, e.g.
mutex_init(&sc->sc_lock, NULL, MUTEX_DRIVER, ibc);
that when you acquired the mutex or released the mutex, the Solaris code
was careful to keep a reference count on the SPL. Reading the code, it
looks to me like it just restores the previous SPL.
So, in other words, if I have two mutexes, a and b, both initialized
with a iblock cookie, I wonder if the following the code has a race
condition:
mutex_enter(&a); (a->old_spl = none, a->new_spl = block); SPL=block
mutex_enter(&b); (b->old_spl = block, b->new_spl = block); SPL=block
mutex_exit(&a); SPL=a->old_spl = none
mutex_exit(&b); SPL=b->old_spl = block
Note that I have out of order mutex exits! Above it looks like there
are two bugs. First, when all is done, no processor SPL should be set,
but instead I have left it set. Second, there appears to be a race
between the mutex exits where the SPL is dropped but should not be.
This behavior would _not_ correspond to my understanding of how mutexes
on Solaris behaved prior to today. I've always assumed the SPL was a
reference counted thing, so that the spl was always raised as long as a
lock suitably initialized was held.
Am I misreading the code today, or is my recent read correct, and lots
of my own code which doesn't take care of this properly busted? (I
understand that mutexes must be _acquired_ in order to prevent deadlock,
but I never thought that this rule applied to their release as well.)
--
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134 Fax: 951 325-2191
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
