mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Peter Zijlstra <peterz@infradead.org>, Marco Elver <elver@google.com>
Cc: Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
	Boqun Feng <boqun@kernel.org>, Waiman Long <longman@redhat.com>,
	linux-kernel@vger.kernel.org,
	"Paul E . McKenney" <paulmck@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Nathan Chancellor <nathan@kernel.org>
Subject: Re: [PATCH 08/14] lockdep: Introduce lockdep_assume_ctx_held()
Date: Thu, 5 Nov 2026 09:00:52 -0800	[thread overview]
Message-ID: <300807c3-7892-4c82-93c9-d069c7fe6208@acm.org> (raw)
In-Reply-To: <20261105145844.GQ1813469@noisy.programming.kicks-ass.net>

On 11/5/26 6:58 AM, Peter Zijlstra wrote:
> Aaah, so the 'solution' is to rename lockdep_assert_held(), such that
> the pre-existing annotation doesn't pre-pollute things?

Yes.

> But if you start
> by converting existing lockdep_assert_held() to the new
> lockdep_assume_*_ctx_held() you'll run into the exact same problems?

The number of lockdep_assert_held() users that has to be modified is
very small. There are only three cases in the entire kernel tree: futex,
kfence and Bluetooth. There three changes have been included in this
patch series. I have verified this by adding lock context annotations in
the entire kernel tree and by enabling lock context analysis for the
entire kernel tree. I'm sending the patches that add lock context
annotations to kernel maintainers as time permits. An example is
available here: "[PATCH v4 00/54] scsi: Enable context analysis for most
drivers"
(https://lore.kernel.org/linux-scsi/cover.1790360262.git.bvanassche@acm.org/).

Thanks,

Bart.

  reply	other threads:[~2026-11-05 17:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-02 21:34 [PATCH 00/14] Stop lockdep_assert_held*() from assuming lock ownership Bart Van Assche
2026-11-02 21:34 ` [PATCH 01/14] bit_spinlock: Fix the __bitlock() definition Bart Van Assche
2026-11-02 21:34 ` [PATCH 02/14] cleanup: Disable context analysis for __free() helpers Bart Van Assche
2026-11-02 21:34 ` [PATCH 03/14] tracing: Disable branch profiling for COMPILE_TEST builds Bart Van Assche
2026-11-02 21:34 ` [PATCH 04/14] srcu: Remove check from srcu_dereference_check() Bart Van Assche
2026-11-02 21:34 ` [PATCH 05/14] futex: Annotate __attach_to_pi_owner() and fixup_pi_*owner() Bart Van Assche
2026-11-02 21:34 ` [PATCH 06/14] locking/rwsem: Annotate rwsem internal functions with __must_hold() Bart Van Assche
2026-11-02 21:34 ` [PATCH 07/14] nvme-fabrics: Annotate nvmf_lookup_transport() with __must_hold_shared() Bart Van Assche
2026-11-03  7:51   ` Christoph Hellwig
2026-11-03 20:37     ` Bart Van Assche
2026-11-04  7:13       ` Christoph Hellwig
2026-11-02 21:34 ` [PATCH 08/14] lockdep: Introduce lockdep_assume_ctx_held() Bart Van Assche
2026-11-05  8:37   ` Peter Zijlstra
2026-11-05 14:39     ` Marco Elver
2026-11-05 14:58       ` Peter Zijlstra
2026-11-05 17:00         ` Bart Van Assche [this message]
2026-11-05 16:52     ` Bart Van Assche
2026-11-02 21:34 ` [PATCH 09/14] kfence: Use lockdep_assume_ctx_held() in kfence_report_error() Bart Van Assche
2026-11-02 21:34 ` [PATCH 10/14] Bluetooth: Add lock context annotations for connection aliases Bart Van Assche
2026-11-02 21:34 ` [PATCH 11/14] futex: Verify exit_mutex ownership in futex_exit_recursive() Bart Van Assche
2026-11-02 21:34 ` [PATCH 12/14] lockdep: Stop lockdep_assert_held*() from assuming lock ownership Bart Van Assche
2026-11-02 21:34 ` [PATCH 13/14] compiler-context-analysis: Split the RCU assertion tests Bart Van Assche
2026-11-02 21:34 ` [PATCH 14/14] rcu: Introduce lockdep_assume_in_rcu_*() Bart Van Assche

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=300807c3-7892-4c82-93c9-d069c7fe6208@acm.org \
    --to=bvanassche@acm.org \
    --cc=akpm@linux-foundation.org \
    --cc=boqun@kernel.org \
    --cc=elver@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mingo@redhat.com \
    --cc=nathan@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=will@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®