options WITNESS and locks

[Kris Kennaway]

Yony Yossef wrote:
> 
>         Something is still unclear. All my locks are MTX_DEF type, which
>         means
>         sleepable, including the one specified in the crash report
>         (MTNIC state
>         semaphore).
>         This crash happens when I try to call bus_resource_alloc_any for
>         a SYS_REQ
>         which is trying to obtain the second lock (ACPI root bus). How
>         come my
>         MTX_DEF lock is being treated as as non-sleepable?
> 
> 
>     MTX_DEF locks *are* non-sleepable :-)
> 
>     Kris
> 
>  
>  
> Good news :-)
> Yet the documentation is confusing me:
>  
> man pages say:
> MTX_DEF        Default mutexes will always allow the current thread to be
>                     suspended to avoid deadlock conditions against interrupt
>                     threads.  The implementation of this lock type may spin
>                     for a while before suspending the current thread.
> and in mutex.h:
> /*
>  * Mutex types and options passed to mtx_init().  MTX_QUIET and MTX_DUPOK
>  * can also be passed in.
>  */
> #define MTX_DEF  0x00000000 /* DEFAULT (sleep) lock */
> #define MTX_SPIN 0x00000001 /* Spin lock (disables interrupts) */
> #define MTX_RECURSE 0x00000004 /* Option: lock allowed to recurse */
> #define MTX_NOWITNESS 0x00000008 /* Don't do any witness checking. */
> #define MTX_NOPROFILE   0x00000020 /* Don't profile this lock */
>  
>  
> What does the "DEFAULT (sleep) lock" comment near MTX_DEF means?
> And which ones are sleepable?..  I guess I'm missing something here. 
>  

"sleep mutex" means that the mutex holder may be put to sleep by the 
kernel while the mutex is held by another process (if the lock holder is 
running then it will spin, though).  It is in contrast to "spin" mutexes 
that always spin forever while the lock is held, even when it might be 
inefficient for them to do so because the lock holder is no longer 
running after the CPU context switched to another process before it 
released the lock.

This describes the behaviour of the mutex while it is waiting to acquire 
a lock.

"sleepable" vs "non-sleepable" locks means what it is legal for your 
code to do while holding a mutex and doesn't relate to the internal 
implementation of the lock.

This describes what it is legal for your code to do once it has acquired 
the lock.

Kris