Re: [PATCH v5 04/10] rust: sync: atomic: Add generic atomics
Boqun Feng <[email protected]>
| Newsgroups | dev.linux.lists.lkmm,org.kernel.vger.linux-arch,org.kernel.vger.linux-kernel,org.kernel.vger.rust-for-linux |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Jun 23, 2025 at 01:54:38PM +0200, Benno Lossin wrote: > On Mon Jun 23, 2025 at 7:19 AM CEST, Boqun Feng wrote: > > On Sat, Jun 21, 2025 at 12:32:12PM +0100, Gary Guo wrote: > >> Note tha the transparent new types restriction on `AllowAtomic` is not > >> sufficient for this, as I can define > >> > > > > Nice catch! I do agree we should disallow `MyWeirdI32`, and I also agree > > that we should put transmutability as safety requirement for > > `AllowAtomic`. However, I would suggest we still keep > > `into_repr`/`from_repr`, and require the implementation to make them > > provide the same results as transmute(), as a correctness precondition > > (instead of a safety precondition), in other words, you can still write > > a `MyWeirdI32`, and it won't cause safety issues, but it'll be > > incorrect. > > Hmm I don't like keeping the function when we add the transmute > requirement. > > > The reason why I think we should keep `into_repr`/`from_repr` but add > > a correctness precondition is that they are easily to implement as safe > > code for basic types, so it'll be better than a transmute() call. Also > > considering `Atomic<*mut T>`, would transmuting between integers and > > pointers act the same as expose_provenance() and > > from_exposed_provenance()? > > Hmmm, this is indeed a problem for pointers. I guess we do need the > functions... > > But this also prevents us from adding the transmute requirement, as it > doesn't hold for pointers. Maybe we need to add the requirement that The requirement is "transumability", which requires any valid binary representation of `T` must be a valid binary representation of `T::Repr`, and we need it regardless whether we use `transumate()` or not in the implementation. Because for the current implementation, `from_ptr()` and any atomics may read a value from `Atomic::new()` needs this. Even if we change the implementation to `Opaque<T::Repr>`, we still need it for `get_mut()` > `into_repr`/`from_repr` preserve the binary representation? We need this too, but just maybe not for safety reasons. Besides, the precondition that we can say `into_repr`/`from_repr` can preserve binary representation is the transmutability requirement. Regards, Boqun > > --- > Cheers, > Benno