Le 24/02/14 18:38, Mindaugas Rasiukevicius a écrit :
Yann Sionneau <[email protected]> wrote:
I've tried to understand how ci_mtx_count is supposed to be managed my
MD code, so far I failed to understand.
It seems some arch use spin_mutex and inc/dec ci_mtx_count upon
spin_mutex_enter/exit.
Some other archs do it in softint handling.
Could someone give my some clue (or documentation) about the intended
behaviour of curcpu()->ci_mtx_count please?
It is a reference count on the IPL raised by spin-mutexes. The IPL should
be lowered (straight to IPL_NONE) on a last reference. Notice that this is
a negative counter - mutex_spin_enter() decrements, while mutex_spin_exit()
incremenets. Not the other way round.
Why should curcpu()->ci_mtx_count be -1 during mi_switch()?
Using watchpoint I discovered that I never access cpu0->ci_mtx_count.
This, as you said, should be incremented/decremented upon
mutex_spin_enter or exit, but in my case mutex_spin_enter() is aliased
to mutex_vector_enter because I don't have any stubs and anyway I have
enabled LOCKDEBUG kernel option.
mutex_spin_enter() only touches curcpu()->ci_mtx_count when the mutex is
a MUTEX_SPIN, I put a breakpoint in mutex_init() and tested all "type"
argument: I never initialize any MUTEX_SPIN.
It seems I only use MUTEX_DEFAULT or MUTEX_DRIVER.
Do I miss a MUTEX_SPIN somewhere? which spin mutex is supposed to be
held before calling mi_switch()? (or at least before the KASSERTMSG
happens).
Thank you for your help :)
--
Yann Sionneau
