Re: [PATCH] rust: page: add volatile memory copy methods

[Boqun Feng <boqun@kernel.org>]

On Fri, Jan 30, 2026 at 05:20:11PM +0100, Andreas Hindborg wrote:
[...]
> >> In the last discussions we had on this, the conclusion was to use
> >> `volatile_copy_memory` whenever that is available, or write a volatile
> >> copy function in assembly.
> >>
> >> Using memcpy_{from,to}io is the latter solution. These functions are
> >> simply volatile memcpy implemented in assembly.
> >>
> >> There is nothing special about MMIO. These functions are name as they
> >> are because they are useful for MMIO.
> >
> > No. MMIO are really special. A few architectures require them to be accessed
> > completely differently compared to normal memory. We also have things like
> > INDIRECT_IOMEM. memory_{from,to}io are special as they use MMIO accessor such as
> > readb to perform access on the __iomem pointer. They should not be mixed with
> > normal memory. They must be treated as if they're from a completely separate
> > address space.
> >
> > Normal memory vs DMA vs MMIO are all distinct, and this is demonstrated by the
> > different types of barriers needed to order things correctly for each type of
> > memory region.
> >
> > Userspace-mapped memory (that is also mapped in the kernel space, not __user) is
> > the least special one out of these. They could practically share all atomic infra
> > available for the kernel, hence the suggestion of using byte-wise atomic memcpy.
> 
> I see. I did not consider this.
> 
> At any rate, I still don't understand why I need an atomic copy function, or why I
> need a byte-wise copy function. A volatile copy function should be fine, no?
> 

but memcpy_{from,to}io() are not just volatile copy functions, they have
additional side effects for MMIO ;-)

> And what is the exact problem in using memcpy_{from,to}io. Looking at
> it, I would end up writing something similar if I wrote a copy function
> myself.
> 
> If it is the wrong function to use, can you point at a fitting funciton?
> 

I *think* for your use cases, a `user_page.read_volatile()` should
suffice if the only potential concurrent writer is in the userspace
(outside the Rust AM). The reason/rule I'm using is: a volatile
operation may race with an access that compiler can know about (i.e.
from Rust and C code), but it will not race with an external access.

However, byte-wise atomic memcpy will be more defined without paying any
extra penalty.

Regards,
Boqun

> 
> Best regards,
> Andreas Hindborg
> 
>