options WITNESS and locks

[Yony Yossef]

Problem solved :-)
Thank you very much for your patience Kris..

On Tue, Jul 15, 2008 at 5:14 PM, Kris Kennaway <kris at freebsd.org> wrote:

>  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
>
>