Questions about locking; turnstiles and sleeping threads
Garrett Cooper
yaneurabeya at gmail.com
Thu Nov 13 17:56:10 UTC 2014
> On Nov 13, 2014, at 09:32, Adrian Chadd <adrian at freebsd.org> wrote:
>
>> On 13 November 2014 06:48, John Baldwin <jhb at freebsd.org> wrote:
>>> On Thursday, November 13, 2014 4:52:50 am Adrian Chadd wrote:
>>> Hm, the more I dig into this, the more I realise it's not a 1:45am
>>> question to ask.
>>>
>>> Specifically, callout_stop_safe() takes 'safe', which says "are we
>>> waiting around for this callout to finish if it started". Ie,
>>> callout_drain() is callout_stop_safe(c, 1) ; callout_stop() is
>>> callout_stop_safe(c, 0).
>>>
>>> If safe is 1, then it'll potentially put the current thread to sleep
>>> in order to wait for it to synchronise with the callout that's
>>> running. It's sleeping with cc_lock which is the per-callwheel lock
>>> and it's doing that with whatever other locks are held. That's the
>>> situation which is tripping things up.
>>>
>>> The manpage says that no locks should be held that the callout may
>>> block on, which isn't the case here at all - I'm trying to grab a lock
>>> in another thread that the caller _into_ the callout subsystem holds.
>>> The manpage doesn't mention anything about this. Sniffle.
>>
>> It should just say "no sleepable locks at all". And yes, callout_stop() is
>> perfectly fine to call with locks held. It is only callout_drain() that
>> should not be called, same as with bus_teardown_intr() and taskqueue_drain()
>> (other routines that can sleep while ensuring that an asynchronous task run
>> by another thread is stopped).
>
> so, we should add WITNESS_WARN() to those as well?
This might be related to the issue Steve Kargl brought up in the thread "shutdown or ACPI problem" on -current at .
More information about the freebsd-arch
mailing list