On 11/17/10 13:26, Thor Lancelot Simon wrote:
On Wed, Nov 17, 2010 at 12:30:59PM +0100, Johnny Billquist wrote:
There are obviously a lot of calls to mutex_enter and mutex_exit with
spin mutexes...
Indeed there are. I don't underestand what Matt said about this. When
I was converting /dev/crypto to mutexes I am pretty sure it was explained
to me that the _spin forms of the calls were simply optimizations for when
the programmer knew the mutex to be a spin mutex due to the IPL at which
it was declared. That is, I had a a pile of driver code full of mutex_enter
and mutex_exit which were on a high-IPL mutex and I simply converted it all
to mutex_spin_enter and mutex_spin_exit with qsubst.
Hmm. Interesting point. So far I have not had any calls to
mutex_spin_exit() with an adaptive lock. So it would appear that what
you say might be how code is written.
Perhaps the rule is that if you take the mutex with spin_enter you must
release it with spin_exit. That would make some sense. But I'd love some
clarity on this point.
That is not the case in the code today. When I was hunting down a
problem, I found just such a situation, where the mutex had been taken
by a call to mutex_spin_enter, and then released with mutex_exit (this
in uvm).
Also a fair number of calls to mutex_spin_exit with the spin lock not
appearing to be held (I actually set and clear a bit to indicate if the
mutex is held, in addition to bumping the IPL).
This *does* seem like a bug.
Might be. But it might also just be something getting messed up because
maybe spin mutexes can be taken through mutex_vector_enter without ever
passing through mutex_spin_enter under some circumstances, and so my
marking of the mutex as being used never happens.
But you could perhaps argue that this is a bug in itself, and
mutex_vector_enter should not take a spin mutex on its own when a
mutex_spin_enter function exist.
Johnny
