On 02/25/2014 11:04 PM, Mindaugas Rasiukevicius wrote:
Yann Sionneau <[email protected]> wrote:
It asserts for -1 because only the LWP lock should be held at that
point.
Ok, but locking the LWP lock won't make ci_mtx_count be -1 because the
lock is a MUTEX_DEFAULT and not a MUTEX_SPIN.
MUTEX_DEFAULT can either mean a spin-lock or an adaptive lock, depending
on the specified IPL value. Please see mutex(9) manpage for details. All
LWP locks (i.e. the locks which can be associated with lwp_t::l_mutex) are
spin-locks.
Ok I understand now, I should have read the mutex_init() code more
carefully, I understand now that basically (almost) all mutex are
initialized with mutex_init(type=MUTEX_DEFAULT, ipl=something)
but then the type of the mutex is computed by checking the ipl value in
the first switch(type) :
http://nxr.netbsd.org/source/xref/src/sys/kern/kern_mutex.c#305
The issue in my code was that for me all IPL_** different than IPL_NONE
were the same value.
So all mutexes were detected as "ADAPTIVE" mutexes and no spin mutexes
were used at all.
By using different values for IPL_HIGH IPL_SCHED and IPL_VM (and
different than the IPL_SOFTXXX and IPL_NONE ones), now it does not
trigger anymore the KASSERTMSG :)
Problem solved! Thanks :)
--
Yann Sionneau
