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

[Andreas Hindborg <a.hindborg@kernel.org>]

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

> On Sat, Jan 31, 2026 at 02:19:05PM +0100, Andreas Hindborg wrote:
> [..]
>> >
>> > 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?
>>
>
> I don't understand your question, so allow me to explain what I meant:
> for the sake of discussion, let's assume we have both
>
> 	fn volatile_copy_memory(src: *mut u8, dst: *mut u8, count: usize)
>
> and
>
> 	fn volatile_byte_wise_atomic_copy_memory(<same signature>, ordering: Ordering)
>
> implemented. What I meant was to the best of my knowledge, when ordering
> = Relaxed, these two would generate the exact same code because all the
> architectures that I'm aware of have byte wise atomicity in the
> load/store instructions. And compared to volatile_copy_memory(),
> volatile_byte_wise_atomic_copy_memory() can bear the race with another
> volatile_byte_wise_atomic_copy_memory() or any other atomic access
> (meaning that's not a UB). So I'd prefer using that if we have it.

Ok, thanks for clarifying. I assumed you were referring to the other
functions I mentioned, because they exist in `kernel` or `core`.
`volatile_copy_memory` is unstable in `core`, and as far as I know
`volatile_byte_wise_atomic_copy_memory` does not exist.

When you wrote `read_volatile`, I assumed you meant
`core::ptr::read_volatile`, and the atomics we have are
`kernel::sync::atomic::*`.

So now I am a bit confused as to what method you think is usable here.
Is it something we need to implement?

Best regards,
Andreas Hindborg