Le 24/02/14 18:38, Mindaugas Rasiukevicius a écrit :
Yann Sionneau <yann.sionneau%gmail.com@localhost> 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