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

[Boqun Feng <boqun.feng@gmail.com>]

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@gmail.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 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