Re: [PATCH v5 6/7] locking/lockdep: Reuse freed chain_hlocks entries

From: Waiman Long
Date: Wed Feb 05 2020 - 09:03:36 EST


On 2/5/20 4:48 AM, Peter Zijlstra wrote:
> On Tue, Feb 04, 2020 at 11:57:09AM -0500, Waiman Long wrote:
>
>> Wait, it is possible that we can have deadlock like this:
>>
>> Â cpu 0ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ cpu 1
>> Â -----ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ -----
>> Â lock AÂÂÂÂÂÂÂÂÂÂÂÂÂ lock B
>> Â <irq>ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ <irq>
>> Â lock BÂÂÂÂÂÂÂÂÂÂÂÂÂ lock A
>> Â
>> If we eliminate 1-entry chain, will that impact our ability to detect this
>> kind of deadlock?
> I'm thinking that should trigger irq-inversion (irq-on vs in-irq) on
> either A or B (depending on timing).
>
> AFAICT the irq-state tracking is outside of validate_chain().
>
> This is also why I think your separate_irq_context() change is not
> needed.
>
> validate_chain() really only checks the per-context lock nesting, and
> there, a single lock doesn't do very much. Hence my proposed patch.
>
I see. Then it may be OK. I will take a further look just to be sure.

Cheers,
Longman