All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Waiman Long <longman@redhat.com>
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 v2 2/6] locking/lockdep: Throw away all lock chains with zapped class
Date: Mon, 13 Jan 2020 16:18:06 +0100	[thread overview]
Message-ID: <20200113151806.GW2844@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20191216151517.7060-3-longman@redhat.com>

On Mon, Dec 16, 2019 at 10:15:13AM -0500, Waiman Long wrote:
> If a lock chain contains a class that is zapped, the whole lock chain is
> now invalid.

Possibly. But I'm thinking that argument can/should be made mode elaborate.

Suppose we have A->B->C, and we're about to remove B.

Now, I suppose the trivial argument goes that if we remove the text that
causes A->B, then so B->C will no longer happen. However, that doesn't
mean A->C won't still occur.

OTOH, we might already have A->C and so our resulting chain would be a
duplicate. Conversely, if we didn't already have A->C and it does indeed
still occur (say it was omitted due to the redundant logic), then we
will create this dependency the next time we'll encounter it.

Bart, do you see a problem with this reasoning?

In short, yes, I think you're right and we can remove the whole thing.
But please, expand the Changelog a bit, possibly add some of this
reasoning into a comment.


  reply	other threads:[~2020-01-13 15:18 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-16 15:15 [PATCH v2 0/6] locking/lockdep: Reuse zapped chain_hlocks entries Waiman Long
2019-12-16 15:15 ` [PATCH v2 1/6] locking/lockdep: Track number of zapped classes Waiman Long
2020-01-13 14:55   ` Peter Zijlstra
2020-01-13 14:58     ` Waiman Long
2020-01-13 16:02       ` Bart Van Assche
2019-12-16 15:15 ` [PATCH v2 2/6] locking/lockdep: Throw away all lock chains with zapped class Waiman Long
2020-01-13 15:18   ` Peter Zijlstra [this message]
2020-01-13 15:44     ` Waiman Long
2020-01-13 16:05     ` Bart Van Assche
2020-01-13 16:15       ` Waiman Long
2019-12-16 15:15 ` [PATCH v2 3/6] locking/lockdep: Track number of zapped lock chains Waiman Long
2019-12-16 15:15 ` [PATCH v2 4/6] locking/lockdep: Reuse freed chain_hlocks entries Waiman Long
2020-01-13 15:51   ` Peter Zijlstra
2020-01-13 16:04     ` Waiman Long
2020-01-13 15:58   ` Peter Zijlstra
2020-01-13 16:24     ` Waiman Long
2020-01-14  9:46       ` Peter Zijlstra
2020-01-14 19:16         ` Waiman Long
2020-01-15 10:44           ` Peter Zijlstra
2020-01-15 19:26             ` Waiman Long
2020-01-13 15:59   ` Peter Zijlstra
2020-01-13 16:03     ` Waiman Long
2019-12-16 15:15 ` [PATCH v2 5/6] locking/lockdep: Decrement irq context counters when removing lock chain Waiman Long
2020-01-14  9:53   ` Peter Zijlstra
2020-01-14 15:04     ` Waiman Long
2019-12-16 15:15 ` [PATCH v2 6/6] locking/lockdep: Display irq_context names in /proc/lockdep_chains Waiman Long
2020-01-06 15:54 ` [PATCH v2 0/6] locking/lockdep: Reuse zapped chain_hlocks entries Waiman Long
2020-01-06 16:50   ` Peter Zijlstra
2020-01-06 16:52     ` 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=20200113151806.GW2844@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bvanassche@acm.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mingo@redhat.com \
    --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.