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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241005143106.1196fd3a.gary@garyguo.net>
Date: Sat, 5 Oct 2024 14:31:06 +0100
From: Gary Guo <gary@...yguo.net>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: 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>, Alice Ryhl <aliceryhl@...gle.com>, 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, 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.

It might also be useful for debugging, so we can have a `Debug` impl
for `Refcount` which prints out the current value. But I didn't
introduce it due to no user.

Best,
Gary

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ