Questions about locking; turnstiles and sleeping threads

[Adrian Chadd]

On 14 November 2014 01:31, Alfred Perlstein <alfred at freebsd.org> wrote:
>
> 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.

Right. Well, I'll see about getting a WITNESS check inserted there so
no other badly behaving code creeps in.



-adrian