Message-ID: <87pl6prkc6.fsf@t14s.mail-host-address-is-not-set>
Date: Sat, 31 Jan 2026 14:19:05 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: Boqun Feng <boqun@...nel.org>
Cc: Gary Guo <gary@...yguo.net>, Alice Ryhl <aliceryhl@...gle.com>, Lorenzo
 Stoakes <lorenzo.stoakes@...cle.com>, "Liam R. Howlett"
 <Liam.Howlett@...cle.com>, Miguel Ojeda <ojeda@...nel.org>, Boqun Feng
 <boqun.feng@...il.com>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, Benno
 Lossin <lossin@...nel.org>, Trevor
 Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>,
 linux-mm@...ck.org, rust-for-linux@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rust: page: add volatile memory copy methods

"Boqun Feng" <boqun@...nel.org> writes:

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

Alright. For the sake of my curiosity, could you explain these
additional side effects and the way thy are handled in the
implementation of these functions?

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

That is my reasoning as well.

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

Could you explain the additional penalty of `core::ptr::read_volatile`
vs `kernel::sync::atomic::Atomic::load` with  relaxed ordering?


Best regards,
Andreas Hindborg

Powered by blists - more mailing lists