Re: [PATCH v2] rust: page: add byte-wise atomic memory copy methods

[Peter Zijlstra]

On Tue, Feb 17, 2026 at 10:47:03AM +0000, Alice Ryhl wrote:

> > Stop using atomic for this. Is not atomic.
> > 
> > Key here is volatile, that indicates value can change outside of scope
> > and thus re-load is not valid. And I know C language people hates
> > volatile, but there it is.
> 
> Well, don't complain to me about this. I sent a patch to add READ_ONCE()/
> WRITE_ONCE() impls for Rust and was told to just use atomics instead,
> see: https://lwn.net/Articles/1053142/

*groan*

> > > 	// OK!
> > > 	unsigned long *a, b;
> > > 	b = READ_ONCE(a);
> > > 	if is_valid(b) {
> > > 	    // do stuff
> > > 	}
> > > 
> > > Now consider the following code:
> > > 
> > > 	// Is this ok?
> > > 	unsigned long *a, b;
> > > 	memcpy(a, &b, sizeof(unsigned long));
> > > 	if is_valid(b) {
> > > 	    // do stuff
> > > 	}
> > 
> > Why the hell would you want to write that? But sure. I think similar but
> > less weird example would be with structures, where value copies end up
> > being similar to memcpy.
> 
> I mean sure, let's say that it was a structure or whatever instead of a
> long. The point is that the general pattern of memcpy, then checking the
> bytes you copied, then use the bytes you copied, is potentially
> susceptible to this exacty optimization.

> > And in that case, you can still use volatile and compiler must not do
> > silly.
> 
> What you mean by "volatile" here is the same as what this patch means
> when it says "per-byte atomic". If you agree that a "volatile memcpy"
> would be a good idea to use in this scenario, then it sounds like you
> agree with the patch except for its naming / terminology.

  struct foo {
    int a, b;
  };

  struct foo *ptr, val;

  val = *(volatile struct foo *)ptr;

why would we need a an explicit new memcpy for this?

> > So I'm still not exactly sure why this is a problem all of a sudden?
> 
> I mean, this is for `struct page` specifically. If you have the struct
> page for a page that might also be mapped into a userspace vma, then the
> way to perform a "copy_from_user" operation is to:
> 
> 1. kmap_local_page()
> 2. memcpy()
> 3. kunmap_local()
> 
> Correct me if I'm wrong, but my understanding is that on 64-bit systems,
> kmap/kunmap are usually complete no-ops since you have enough address
> space to simply map all pages into the kernel's address space. Not even
> a barrier - just a `static inline` with an empty body.

That is all correct -- however that cannot be all you do.

Any shared memory will involved memory barriers of a sort. You cannot
just memcpy() and think you're done.

So yeah, on x86_64 those 1,2,3 are insufficient to inhibit the re-load,
but nobody should ever just do 1,2,3 and think job-done. There must
always be more.

If it is a ring-buffer like thing, you get:

         *   if (LOAD ->data_tail) {            LOAD ->data_head
         *                      (A)             smp_rmb()       (C)
         *      STORE $data                     LOAD $data
         *      smp_wmb()       (B)             smp_mb()        (D)
         *      STORE ->data_head               STORE ->data_tail
         *   }

if it is a seqlock like thing you get that.

If it is DMA, you need dma fences.

And the moment you use any of that, the re-load goes out the window.