Questions about locking; turnstiles and sleeping threads

[Alfred Perlstein]

On Nov 13, 2014, at 9:31 AM, Adrian Chadd wrote:

> On 13 November 2014 02:14, Alfred Perlstein <alfred at freebsd.org> wrote:
>> Would need more context to help on this.
>> 
>> I can't tell based on your description which thread is holding which lock.
>> 
>> If A is waiting for callout C to stop AND there exists a thread B that is
>> contending against C for a lock, you should be fine so long as there is no
>> lock cycle against A.
>> 
>> Would be best if you pointed at some code and gave descriptions.
> 
> I haven't dug into the USB side of things ,but on the atheros side I
> gave the description above.
> 
> Thread A grabs lock X and tries to drain callout, which involves
> grabbing lock Y to do the dirty work. Lock Y isn't held at this point
> - the callout is about to run or is running, so it enters the sleepq
> call to finish the drain.
> 
> Thread B wants to grab lock X, but can't because thread A holds lock X
> and is in a sleepq due to callout_drain(). Hence panic.
> 
> I'll poke people on IRC today and see if I can get a better
> description of what/where the WITNESS_WARN() should be placed in
> callout_drain(). Then we'll see what's left triggering it.


Yes, this is exactly how one is not supposed to use callout_drain().

From the context of the caller of callout_drain() you are better off doing a stop() under the lock, then dropping the lock and doing the drain.  Typically one sets a "dying" or "going away" type flag in the softc to prevent more callouts from being scheduled.

-Alfred