From: Peter Zijlstra <peterz@infradead.org>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: linux-kernel@vger.kernel.org, linux-bcachefs@vger.kernel.org,
boqun.feng@gmail.com, longman@redhat.com, will@kernel.org,
mingo@redhat.com
Subject: Re: [PATCH 2/6] locking/lockdep: lockdep_set_no_check_recursion()
Date: Fri, 24 Nov 2023 10:58:04 +0100 [thread overview]
Message-ID: <20231124095804.GO3818@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20231122235113.180132-3-kent.overstreet@linux.dev>
On Wed, Nov 22, 2023 at 06:51:09PM -0500, Kent Overstreet wrote:
> This adds a method to tell lockdep not to check lock ordering within a
> lock class - but to still check lock ordering w.r.t. other lock types.
>
> This is for bcachefs, where for btree node locks we have our own
> deadlock avoidance strategy w.r.t. other btree node locks (cycle
> detection), but we still want lockdep to check lock ordering w.r.t.
> other lock types.
So earlier you added custom sort order.
Additionally there is the wound-wait mutexes that also have semantics
similar to what you describe.
Explain why you can't use either your own added feature or the existing
infrastructure to solve this?
next prev parent reply other threads:[~2023-11-24 9:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-22 23:51 [PATCH 0/6] lockdep enhancements for bcachefs Kent Overstreet
2023-11-22 23:51 ` [PATCH 1/6] locking/lockdep: lock_class_is_held() Kent Overstreet
2023-11-22 23:51 ` [PATCH 2/6] locking/lockdep: lockdep_set_no_check_recursion() Kent Overstreet
2023-11-24 9:58 ` Peter Zijlstra [this message]
2023-11-24 23:29 ` Kent Overstreet
2023-11-22 23:51 ` [PATCH 3/6] bcachefs: Assert that btree node locks aren't being leaked Kent Overstreet
2023-11-22 23:51 ` [PATCH 4/6] bcachefs: Use lock_class_is_held() for btree locking asserts Kent Overstreet
2023-11-22 23:51 ` [PATCH 5/6] bcachefs: Check for btree locks held on transaction init Kent Overstreet
2023-11-22 23:51 ` [PATCH 6/6] bcachefs: Switch to lockdep_set_no_check_recursion() Kent Overstreet
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=20231124095804.GO3818@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=boqun.feng@gmail.com \
--cc=kent.overstreet@linux.dev \
--cc=linux-bcachefs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--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