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