All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boqun Feng <boqun.feng@gmail.com>
To: Benno Lossin <lossin@kernel.org>
Cc: "Gary Guo" <gary@garyguo.net>,
	linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
	lkmm@lists.linux.dev, linux-arch@vger.kernel.org,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Will Deacon" <will@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Wedson Almeida Filho" <wedsonaf@gmail.com>,
	"Viresh Kumar" <viresh.kumar@linaro.org>,
	"Lyude Paul" <lyude@redhat.com>, "Ingo Molnar" <mingo@kernel.org>,
	"Mitchell Levy" <levymitchell0@gmail.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Thomas Gleixner" <tglx@linutronix.de>
Subject: Re: [PATCH v5 04/10] rust: sync: atomic: Add generic atomics
Date: Fri, 4 Jul 2025 15:30:30 -0700	[thread overview]
Message-ID: <aGhWBp3IhfJDhPOs@Mac.home> (raw)
In-Reply-To: <DB3M1FEMKVLN.1BDAD6WHDR7HG@kernel.org>

On Sat, Jul 05, 2025 at 12:05:48AM +0200, Benno Lossin wrote:
[..]
> >> 
> >> I don't think there is a big difference between `Opaque<T>` and
> >> `Opaque<T::Repr>` if we have the transmute equivalence between the two.
> >> From a safety perspective, you don't gain or lose anything by using the
> >> first over the second one. They both require the invariant that they are
> >> valid (as `Opaque` removes that... we should really be using
> >> `UnsafeCell` here instead... why aren't we doing that?).
> >> 
> >
> > I need the `UnsafePinned`-like behavior of `Atomic<*mut T>` to support
> > Rcu<T>, and I will replace it with `UnsafePinned`, once that's is
> > available.
> 
> Can you expand on this? What do you mean by "`UnsafePinned`-like
> behavior"? And what does `Rcu<T>` have to do with atomics?
> 

`Rcu<T>` is an RCU protected (atomic) pointer, the its definition is

    pub struct Rcu<T>(Atomic<*mut T>);

I need Pin<&mut Rcu<T>> and &Rcu<T> able to co-exist: an updater will
have the access to Pin<&mut Rcu<T>>, and all the readers will have the
access to &Rcu<T>, for that I need `Atomic<*mut T>` to be
`UnsafePinned`, because `Pin<&mut Rcu<T>>` cannot imply noalias.

> > Maybe that also means `UnsafePinned<T>` make more sense? Because if `T`
> > is a pointer, it's easy to prove the provenance is there. (Note a
> > `&Atomic<*mut T>` may come from a `*mut *mut T`, may be a field in C
> > struct)
> 
> Also don't understand this.
> 

One of the usage of the atomic is being able to communicate with C side,
for example, if we have a struct foo:

    struct foo {
        struct bar *b;
    }

and writer can do this at C side:

   struct foo *f = ...;
   struct bar *b = kcalloc(*b, ...);

   // init b;

   smp_store_release(&f->b, b);

and a reader at Rust side can do:

    #[repr(transparent)]
    struct Bar(binding::bar);
    struct Foo(Opaque<bindings::foo>);

    fn get_bar(foo: &Foo) {
        let foo_ptr = foo.0.get();

	let b: *mut *mut Bar = unsafe { &raw mut (*foo_ptr).b }.cast();
	// SAFETY: C side accessing this pointer with atomics.
        let b = unsafe { Atomic::<*mut Bar>::from_ptr(b) };

        // Acquire pairs with the Release from C side;
	let bar_ptr = b.load(Acquire);

	// accessing bar.
    }

This is the case we must support if we want to write any non-trivial
synchronization code communicate with C side.

And in this case, it's generally easier to reason why we can convert a
*mut *mut Bar to &UnsafePinned<*mut Bar>.

Regards,
Boqun

> ---
> Cheers,
> Benno

  reply	other threads:[~2025-07-04 22:30 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-18 16:49 [PATCH v5 00/10] LKMM generic atomics in Rust Boqun Feng
2025-06-18 16:49 ` [PATCH v5 01/10] rust: Introduce atomic API helpers Boqun Feng
2025-06-26  8:44   ` Andreas Hindborg
2025-06-27 14:00     ` Boqun Feng
2025-06-18 16:49 ` [PATCH v5 02/10] rust: sync: Add basic atomic operation mapping framework Boqun Feng
2025-06-26  8:50   ` Andreas Hindborg
2025-06-26 10:17   ` Andreas Hindborg
2025-06-27 14:30     ` Boqun Feng
2025-06-18 16:49 ` [PATCH v5 03/10] rust: sync: atomic: Add ordering annotation types Boqun Feng
2025-06-19 10:31   ` Peter Zijlstra
2025-06-19 12:19     ` Alice Ryhl
2025-06-19 13:29     ` Boqun Feng
2025-06-19 14:32       ` Peter Zijlstra
2025-06-19 15:00         ` Boqun Feng
2025-06-19 15:10           ` Peter Zijlstra
2025-06-19 15:15             ` Boqun Feng
2025-06-19 18:04           ` Alan Stern
2025-06-21 11:18   ` Gary Guo
2025-06-23  2:48     ` Boqun Feng
2025-06-26 12:36   ` Andreas Hindborg
2025-06-27 14:34     ` Boqun Feng
2025-06-27 14:44       ` Boqun Feng
2025-06-18 16:49 ` [PATCH v5 04/10] rust: sync: atomic: Add generic atomics Boqun Feng
2025-06-21 11:32   ` Gary Guo
2025-06-23  5:19     ` Boqun Feng
2025-06-23 11:54       ` Benno Lossin
2025-06-23 12:58         ` Boqun Feng
2025-06-23 18:30       ` Gary Guo
2025-06-23 19:09         ` Boqun Feng
2025-06-23 23:27           ` Benno Lossin
2025-06-24 16:35             ` Boqun Feng
2025-06-26 13:54               ` Benno Lossin
2025-07-04 21:22                 ` Boqun Feng
2025-07-04 22:05                   ` Benno Lossin
2025-07-04 22:30                     ` Boqun Feng [this message]
2025-07-04 22:49                       ` Benno Lossin
2025-07-04 23:21                         ` Boqun Feng
2025-07-04 20:25           ` Boqun Feng
2025-07-04 20:45             ` Benno Lossin
2025-07-04 21:17               ` Boqun Feng
2025-07-04 22:38                 ` Benno Lossin
2025-07-04 23:21                   ` Boqun Feng
2025-07-05  8:04                     ` Benno Lossin
2025-07-05 15:38                       ` Boqun Feng
2025-07-05 21:43                         ` Benno Lossin
2025-06-26 12:15   ` Andreas Hindborg
2025-06-27 15:01     ` Boqun Feng
2025-06-30  9:52       ` Andreas Hindborg
2025-06-30 14:44         ` Alan Stern
2025-07-01  8:54           ` Andreas Hindborg
2025-07-01 14:50             ` Boqun Feng
2025-07-02  8:33               ` Andreas Hindborg
2025-06-18 16:49 ` [PATCH v5 05/10] rust: sync: atomic: Add atomic {cmp,}xchg operations Boqun Feng
2025-06-21 11:37   ` Gary Guo
2025-06-23  5:23     ` Boqun Feng
2025-06-26 13:12   ` Andreas Hindborg
2025-06-28  3:03     ` Boqun Feng
2025-06-30 10:16       ` Andreas Hindborg
2025-06-30 14:51         ` Alan Stern
2025-06-30 15:12           ` Boqun Feng
2025-06-27  8:58   ` Benno Lossin
2025-06-27 13:53     ` Boqun Feng
2025-06-28  6:12       ` Benno Lossin
2025-06-28  7:31         ` Boqun Feng
2025-06-28  8:00           ` Benno Lossin
2025-06-30 15:24             ` Boqun Feng
2025-06-30 15:27               ` Boqun Feng
2025-06-30 15:50               ` Benno Lossin
2025-06-18 16:49 ` [PATCH v5 06/10] rust: sync: atomic: Add the framework of arithmetic operations Boqun Feng
2025-06-21 11:41   ` Gary Guo
2025-06-26 12:39   ` Andreas Hindborg
2025-06-28  3:04     ` Boqun Feng
2025-06-18 16:49 ` [PATCH v5 07/10] rust: sync: atomic: Add Atomic<u{32,64}> Boqun Feng
2025-06-26 12:47   ` Andreas Hindborg
2025-06-18 16:49 ` [PATCH v5 08/10] rust: sync: atomic: Add Atomic<{usize,isize}> Boqun Feng
2025-06-26 12:49   ` Andreas Hindborg
2025-06-18 16:49 ` [PATCH v5 09/10] rust: sync: atomic: Add Atomic<*mut T> Boqun Feng
2025-06-18 16:49 ` [PATCH v5 10/10] rust: sync: Add memory barriers Boqun Feng
2025-06-26 13:36   ` Andreas Hindborg
2025-06-28  3:42     ` Boqun Feng
2025-06-30  9:54       ` Andreas Hindborg
2025-06-18 20:22 ` [PATCH v5 00/10] LKMM generic atomics in Rust Alice Ryhl

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=aGhWBp3IhfJDhPOs@Mac.home \
    --to=boqun.feng@gmail.com \
    --cc=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=dakr@kernel.org \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=levymitchell0@gmail.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkmm@lists.linux.dev \
    --cc=lossin@kernel.org \
    --cc=lyude@redhat.com \
    --cc=mark.rutland@arm.com \
    --cc=mingo@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tmgross@umich.edu \
    --cc=torvalds@linux-foundation.org \
    --cc=viresh.kumar@linaro.org \
    --cc=wedsonaf@gmail.com \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.