From: "Gary Guo" <gary@garyguo.net>
To: "Onur Özkan" <work@onurozkan.dev>, "Gary Guo" <gary@garyguo.net>
Cc: <rust-for-linux@vger.kernel.org>, <lossin@kernel.org>,
<lyude@redhat.com>, <ojeda@kernel.org>, <alex.gaynor@gmail.com>,
<boqun.feng@gmail.com>, <a.hindborg@kernel.org>,
<aliceryhl@google.com>, <tmgross@umich.edu>, <dakr@kernel.org>,
<peterz@infradead.org>, <mingo@redhat.com>, <will@kernel.org>,
<longman@redhat.com>, <felipe_life@live.com>, <daniel@sedlak.dev>,
<daniel.almeida@collabora.com>,
<thomas.hellstrom@linux.intel.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v12 5/6] rust: ww_mutex: implement LockSet
Date: Thu, 15 Oct 2026 15:00:07 +0100 [thread overview]
Message-ID: <DM5GSI7K9IE1.32TMUTLAR9WU7@garyguo.net> (raw)
In-Reply-To: <20261015122618.145485-1-work@onurozkan.dev>
On Thu Oct 15, 2026 at 1:26 PM BST, Onur Özkan wrote:
> On Thu, 15 Oct 2026 12:53:10 +0100
> Gary Guo <gary@garyguo.net> wrote:
>
>> If you do not need the "acquire the contended lock first" behaviour, then
>> there's no need for wrapper, even. Also, if this behaviour is truly universal,
>> perhaps it should become part of `AcquireCtx`'s default behaviour instead.
>
> We need that functionality for the DRM use-case, it's not something that should
> be applied to the ww mutex primitives but I would like to hear @Daniel's opinion
> on this.
>
> [snip]
>
> This still needs the contended-lock backoff when retrying the full transaction.
> Simply restarting the callback can repeatedly hit EDEADLK, so the proposed code
> is not going to work.
WW mutex is fair so the transaction will progress eventually when it becomes the
oldest transaction. I think acquring the contended lock first is basically just
a protection against pathological cases where say, old txn and new txn acquires
lock in opposite order, than new txn would have to wound repeatedly as old txn
make its way through..
But regardless I think this behaviour can just become a thin wrapper on
`AcquireCtx` like my earlier email. Something like
#[pin_data]
struct AcquireCtxBackoff<'a> {
#[pin]
ctx: AcquireCtx,
// Set by `lock()` on `EDEADLK`; the mutex remains valid for `'a`.
contended: Option<NonNull<bindings::ww_mutex>>,
contend_acquired: bool,
}
impl<'a> AcquireCtxBackOff<'a> {
fn lock(&mut self, m: &'a Mutex<T>) -> Result<MutexGuard<'_, T>> {
if let Some(contended) = self.contended {
if !self.contended_acquired {
lock contended
}
if m.as_ptr() == contended.as_ptr() {
self.contended = None;
self.contended_acquired = false;
return a guard
}
}
match ... {
Ok(...) => ...,
Err(EDEADLK) => {
if self.contended_acquired {
unlock contended
}
self.contended = Some(m.as_ptr());
Err(EDEADLK)?
}
Err(err) => Err(err)?
}
}
}
Then code that want backoff behaviour can just use this ctx.
Best,
Gary
next prev parent reply other threads:[~2026-10-15 14:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 10:26 [PATCH v12 0/6] rust: add ww_mutex support Onur Özkan
2026-10-12 10:26 ` [PATCH v12 1/6] rust: add C wrappers for ww_mutex inline functions Onur Özkan
2026-10-12 11:41 ` Gary Guo
2026-10-12 10:26 ` [PATCH v12 2/6] ww_mutex: add ww_class field unconditionally Onur Özkan
2026-10-12 11:42 ` Gary Guo
2026-10-15 11:37 ` Onur Özkan
2026-10-12 10:26 ` [PATCH v12 3/6] rust: implement Class for ww_class support Onur Özkan
2026-10-12 11:03 ` Gary Guo
2026-10-12 11:26 ` Onur Özkan
2026-10-12 10:26 ` [PATCH v12 4/6] rust: ww_mutex: add Mutex, AcquireCtx and MutexGuard Onur Özkan
2026-10-12 11:40 ` Gary Guo
2026-10-15 12:13 ` Onur Özkan
2026-10-15 14:10 ` Gary Guo
2026-10-12 10:26 ` [PATCH v12 5/6] rust: ww_mutex: implement LockSet Onur Özkan
2026-10-12 12:02 ` Gary Guo
2026-10-15 11:26 ` Onur Özkan
2026-10-15 11:53 ` Gary Guo
2026-10-15 12:26 ` Onur Özkan
2026-10-15 14:00 ` Gary Guo [this message]
2026-10-12 10:26 ` [PATCH v12 6/6] MAINTAINERS: add Onur Özkan as WW MUTEX maintainer Onur Özkan
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=DM5GSI7K9IE1.32TMUTLAR9WU7@garyguo.net \
--to=gary@garyguo.net \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=daniel@sedlak.dev \
--cc=felipe_life@live.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=lossin@kernel.org \
--cc=lyude@redhat.com \
--cc=mingo@redhat.com \
--cc=ojeda@kernel.org \
--cc=peterz@infradead.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=thomas.hellstrom@linux.intel.com \
--cc=tmgross@umich.edu \
--cc=will@kernel.org \
--cc=work@onurozkan.dev \
/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