[PATCH] OsdSynch.c modernization
nate at root.org
Mon Sep 24 09:52:45 PDT 2007
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 @
>>>> /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
>>> 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
>>> 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.
More information about the freebsd-acpi