From: Waiman Long <longman@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>, Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org,
Bart Van Assche <bvanassche@acm.org>
Subject: Re: [PATCH v5 6/7] locking/lockdep: Reuse freed chain_hlocks entries
Date: Wed, 5 Feb 2020 09:03:28 -0500 [thread overview]
Message-ID: <c3e01215-bb1c-e22a-32e3-f01e2e96584a@redhat.com> (raw)
In-Reply-To: <20200205094838.GI14879@hirez.programming.kicks-ass.net>
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
next prev parent reply other threads:[~2020-02-05 14:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-03 16:41 [PATCH v5 0/7] locking/lockdep: Reuse zapped chain_hlocks entries Waiman Long
2020-02-03 16:41 ` [PATCH v5 1/7] locking/lockdep: Decrement irq context counters when removing lock chain Waiman Long
2020-02-03 16:41 ` [PATCH v5 2/7] locking/lockdep: Display irq_context names in /proc/lockdep_chains Waiman Long
2020-02-03 16:41 ` [PATCH v5 3/7] locking/lockdep: Track number of zapped classes Waiman Long
2020-02-03 16:41 ` [PATCH v5 4/7] locking/lockdep: Throw away all lock chains with zapped class Waiman Long
2020-02-03 16:41 ` [PATCH v5 5/7] locking/lockdep: Track number of zapped lock chains Waiman Long
2020-02-03 16:41 ` [PATCH v5 6/7] locking/lockdep: Reuse freed chain_hlocks entries Waiman Long
2020-02-04 12:36 ` Peter Zijlstra
2020-02-04 14:54 ` Waiman Long
2020-02-04 16:45 ` Waiman Long
2020-02-05 9:41 ` Peter Zijlstra
2020-02-05 13:59 ` Waiman Long
2020-02-04 15:42 ` Peter Zijlstra
2020-02-04 16:12 ` Waiman Long
2020-02-04 16:26 ` Waiman Long
2020-02-04 16:57 ` Waiman Long
2020-02-05 9:48 ` Peter Zijlstra
2020-02-05 14:03 ` Waiman Long [this message]
2020-02-03 16:41 ` [PATCH v5 7/7] locking/lockdep: Add a fast path for chain_hlocks allocation Waiman Long
2020-02-04 12:47 ` Peter Zijlstra
2020-02-04 15:07 ` Waiman Long
2020-02-04 13:18 ` Peter Zijlstra
2020-02-04 13:44 ` Peter Zijlstra
2020-02-04 18:02 ` Waiman Long
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c3e01215-bb1c-e22a-32e3-f01e2e96584a@redhat.com \
--to=longman@redhat.com \
--cc=bvanassche@acm.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.