linux-kernel - Re: [PATCH] rust: sync: document that Guard is not a stable lock guard

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAH5fLgiTRkCoNKFPCVo8EQTSw8xf_JeVGWVQAgYYAWZk72_H-Q@mail.gmail.com>
Date: Mon, 9 Dec 2024 08:36:31 +0100
From: Alice Ryhl <aliceryhl@...gle.com>
To: Boqun Feng <boqun.feng@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, 
	Will Deacon <will@...nel.org>, Waiman Long <longman@...hat.com>, Miguel Ojeda <ojeda@...nel.org>, 
	Alex Gaynor <alex.gaynor@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Trevor Gross <tmgross@...ch.edu>, rust-for-linux@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rust: sync: document that Guard is not a stable lock guard

On Fri, Dec 6, 2024 at 7:28 PM Boqun Feng <boqun.feng@...il.com> wrote:
>
> On Fri, Dec 06, 2024 at 10:56:23AM +0100, Alice Ryhl wrote:
> > On Thu, Dec 5, 2024 at 7:18 PM Boqun Feng <boqun.feng@...il.com> wrote:
> > >
> > > On Thu, Dec 05, 2024 at 12:35:51PM +0000, Alice Ryhl wrote:
> > > > Most locks in the linux kernel are stable, which means that holding the
> > > > lock is sufficient to keep the value from being freed. For example, this
> > > > means that if you acquire a lock on a refcounted value during rcu, then
> > > > you do not need to acquire a refcount to keep it alive past
> > > > rcu_read_unlock().
> > > >
> > > > However, the Rust `Guard` type is written in a way where it cannot be
> > > > used with this pattern. One reason for this is the existence of the
> > > > `do_unlocked` method that is used with `Condvar`. The method allows you
> > > > to unlock the lock, run some code, and then reacquire the lock. This
> > > > operation is not okay if the lock itself is what keeps the value alive,
> > > > as it could be freed right after the unlock call.
> > > >
> > >
> > > Hmm... but `Guard` holds a reference to the corresponding `Lock`. How
> > > could this happen? Do you have an example?
> >
> > Well it can't. The reference is yet another reason that Guard can't be
> > used for stable locking.
> >
> > This doc change arises out of me needing a stable lock for something.
> >
>
> Maybe it's better to put together this patch and the stable locking you
> are working on? It's better for reviewing in that way.

I'm not sure when that will happen.

> I can see what a "stable lock' means, but want to make sure we change
> the doc to reflect the exact requirement of a stable lock.
>
> Regards,
> Boqun
>
> > Alice