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

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Feb 17, 2026 at 11:51:20AM +0000, Alice Ryhl wrote:

> 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);

  barrier();

> if (is_valid(&val)) {
>     // use val
> }
> 
> This exact thing happens in Binder. It has to be a memcpy.

Sure, but then stick that one barrier() in and you're good.


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

Then stick in barrier().