Re: [PATCH] OsdSynch.c modernization

John Baldwin wrote:
> On Monday 24 September 2007 12:11:07 pm Nate Lawson wrote:
>> John Baldwin wrote:
>>> 2007/9/22, Jung-uk Kim <jkim_at_freebsd.org>:
>>>> I thought exactly the same when I started rewriting it (almost half
>>>> year ago!).  I have tried all of the above, spent numerous sleepless
>>>> nights, and miserably failed. :-(
>>>>
>>>> Spin mutex is too restrictive (e.g., it cannot be used with other
>>>> locks gracefully).  critical_enter() causes:
>>>>
>>>> panic: blockable sleep lock (sleep mutex) 32 _at_
>>>> /usr/src/sys/vm/uma_core.c:1830 cpuid = 0
>>>> KDB: enter: panic
>>>> [thread pid 21 tid 100013 ]
>>>> Stopped at      kdb_enter+0x32: leave
>>> However, disabling interrupts while you block on other locks is just as 
> bad, 
>>> we just don't assert for it.  Better would be to fix ACPI-CA to not try to 
>>> malloc() while holding a spin lock.  You should be able to see where it is 
>>> doing that via the stack trace.  If the malloc is using M_NOWAIT you will 
> be 
>>> far better off using a plain mutex and just not disabling interrupts.
>>
>> For 7.0, we're going with what we have (sx locks) since it's well-tested
>> and not wrong, maybe just less than optimal.  Remember that acpi locks
>> are acquired a few dozen times every 10 seconds or so, so this is not at
>> risk of being a performance issue.
> 
> Disabling interrupts and then calling malloc() is wrong however.

Sure, I guess I thought that part would just be removed and we'd deal
with a pure sx lock.  Jung-uk, what was the need for
critical_enter/intr_disable?  The only thing I can think of is that you
might want to prevent a thread from migrating while the "spin" lock is
held.  I don't see that as necessary.

I agree that this part should be removed, but I think we should stick
with sx locks for now and not re-work acpi-ca (vendor code) so close to
a release unless it's something very simple.

-- 
Nate