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

[Alice Ryhl <aliceryhl@google.com>]

On Tue, Feb 17, 2026 at 12:09:11PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 17, 2026 at 10:47:03AM +0000, Alice Ryhl wrote:
> > > > 	// 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?

In my experience with dealing with `struct page` that is mapped into a
vma, you need memcpy because the struct might be split across two
different pages in the vma. The pages are adjacent in userspace's
address space, but not necessarily adjacent from the kernel's POV.

So you might end up with something that looks like this:

struct foo val;
void *ptr1 = kmap_local_page(p1);
void *ptr2 = kmap_local_page(p2);
memcpy(ptr1 + offset, val, PAGE_SIZE - offset);
memcpy(ptr2, val + offset, sizeof(struct foo) - (PAGE_SIZE - offset));
kunmap_local(ptr2);
kunmap_local(ptr1);

if (is_valid(&val)) {
    // use val
}

This exact thing happens in Binder. It has to be a memcpy.

> > > 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.

I don't know how Andreas is using this, but the usage pattern I'm
familiar with for `struct page` from my work on Binder is this one:

1. memcpy into the page
2. return from ioctl
3. userspace reads from vma

or

1. userspace writes to vma
2. call ioctl
3. kernel reads from page

which needs no barriers whatsoever. There is nothing to prevent this
kind of optimization in this kind of code, so an evil userspace could
trigger TOCTOU bugs in the kernel that are not present in the source
code if the code was optimized like I described.

Alice