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