[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAH5fLgj6SPAM0KM2pF1v0gUCJA875VvWxddTCQXu7h+t1tDjfw@mail.gmail.com>
Date: Mon, 7 Oct 2024 14:30:34 +0200
From: Alice Ryhl <aliceryhl@...gle.com>
To: Gary Guo <gary@...yguo.net>
Cc: Greg KH <gregkh@...uxfoundation.org>, Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>,
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>, Martin Rodriguez Reboredo <yakoyoku@...il.com>, Will Deacon <will@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, Mark Rutland <mark.rutland@....com>,
Dirk Behme <dirk.behme@...bosch.com>, linux-kernel@...r.kernel.org,
rust-for-linux@...r.kernel.org
Subject: Re: [PATCH 1/3] rust: implement `kernel::sync::Refcount`
On Sat, Oct 5, 2024 at 4:26 PM Gary Guo <gary@...yguo.net> wrote:
>
> On Sat, 5 Oct 2024 14:31:06 +0100
> Gary Guo <gary@...yguo.net> wrote:
>
> > On Sat, 5 Oct 2024 09:40:53 +0200
> > Greg KH <gregkh@...uxfoundation.org> wrote:
> >
> > > On Fri, Oct 04, 2024 at 04:52:22PM +0100, Gary Guo wrote:
> > > > This is a wrapping layer of `include/linux/refcount.h`. Currently only
> > > > the most basic operations (read/set/inc/dec/dec_and_test) are implemented,
> > > > additional methods can be implemented when they are needed.
> > > >
> > > > Currently the kernel refcount has already been used in `Arc`, however it
> > > > calls into FFI directly.
> > > >
> > > > Cc: Will Deacon <will@...nel.org>
> > > > Cc: Peter Zijlstra <peterz@...radead.org>
> > > > Cc: Boqun Feng <boqun.feng@...il.com>
> > > > Cc: Mark Rutland <mark.rutland@....com>
> > > > Signed-off-by: Gary Guo <gary@...yguo.net>
> > > > ---
> > > > rust/helpers/refcount.c | 15 ++++++
> > > > rust/kernel/sync.rs | 2 +
> > > > rust/kernel/sync/refcount.rs | 94 ++++++++++++++++++++++++++++++++++++
> > > > 3 files changed, 111 insertions(+)
> > > > create mode 100644 rust/kernel/sync/refcount.rs
> > > >
> > > > diff --git a/rust/helpers/refcount.c b/rust/helpers/refcount.c
> > > > index f47afc148ec3..39649443426b 100644
> > > > --- a/rust/helpers/refcount.c
> > > > +++ b/rust/helpers/refcount.c
> > > > @@ -8,11 +8,26 @@ refcount_t rust_helper_REFCOUNT_INIT(int n)
> > > > return (refcount_t)REFCOUNT_INIT(n);
> > > > }
> > > >
> > > > +unsigned int rust_helper_refcount_read(refcount_t *r)
> > > > +{
> > > > + return refcount_read(r);
> > > > +}
> > >
> > > Reading a refcount is almost always a wrong thing to do (it can change
> > > right after you read it), and I don't see any of the later patches in
> > > this series use this call, so can you just drop this?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > I originally introduced this thinking I can replace Andreas's atomic
> > 2->0 operation with a read + set, but ended up couldn't do it.
> >
> > The refcount read is still useful to determine if the current value is
> > 1 -- in fact, `Arc::into_unique_or_drop` could use this rather than
> > decrementing the refcount and then incrementing it again (just doing a
> > refcount read would be much better codegen-wise than the current
> > behaviour). I'll probably make this change in the next version of the
> > series.
>
> Actually `into_unique_or_drop` can't use this because it needs to avoid
> running destructor when it races with other threads. The semantics for
> that function is better reflected with `refcount_dec_not_one`, which
> I'll introduce in v2, and I'll drop `read` in v2.
Ah, I did not know that C had a refcount_dec_not_one. Yeah, that's
exactly what into_unique_or_drop does.
Though I don't know if the cmpxchg loop is really more efficient than
just doing an infallible decrement like I do right now?
Alice
Powered by blists - more mailing lists