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:34:02PM +0100, Andreas Hindborg wrote:
> [..]
>> >
>> > For DMA memory, it can be almost treated as external normal memory,
>> > however, different archictures/systems/platforms may have different
>> > requirement regarding cache coherent between CPU and devices, specially
>> > mapping or special instructions may be needed.
>>
>> Cache flushing and barriers, got it.
>>
>
> For completeness, I think for some architectures/platforms, cache
> coherence between CPU and devices can be achieved by hardware, in that
> case, DMA memory access can be just a normal memory access.
>
>> >
>> > For __user memory, because kernel is only given a userspace address, and
>> > userspace can lie or unmap the address while kernel accessing it,
>> > copy_{from,to}_user() is needed to handle page faults.
>>
>> Just to clarify, for my use case, the page is already mapped to kernel
>> space, and it is guaranteed to be mapped for the duration of the call
>> where I do the copy. Also, it _may_ be a user page, but it might not
>> always be the case.
>>
>
> Ok, if it's not a page mapped to userspace, would there be any other
> access from kernel while copying the page? If there is other kernel
> thread or interrupt could write to source page, the write needs to be
> atomic in some level (byte-wise for example), so does the read part of
> the copy.

No matter if it is a page from user space or a page only mapped in the
kernel, there should be no concurrent access by kernel threads.

These pages are the IO buffers for block device IO. For direct user IO
they would be user space pages mapped to the kernel during IO. For
regular IO, they are managed by the page cache. I am pretty sure proper
locking is in place so that the pages are not mutated or read while an
IO request is outstanding from the page cache.

Maybe encryption could be a case where data is written by kernel threads
(in case of no hw acceleration) to IO buffers mapped in kernel space.
But again, these operations would not overlap with the IO request, and
proper synchronization should be in place.

>
>> >
>> > Your use case (copying between userspace-mapped memory and kernel
>> > memory) is, as Gary said, the least special here. So using
>> > memcpy_{from,to}io() would be overkill and probably misleading.
>>
>> Ok, I understand.
>>
>> > I
>> > suggest we use `{read,write}_volatile()` (unless I'm missing something
>> > subtle of course), however `{read,write}_volatile()` only works on Sized
>> > types,
>>
>> We can copy as u8? Or would it be more efficient to copy as a larger size?
>>
>
> Copying as a larger size is more efficient: less instructions for the
> same amount of data to copy.
>
>> You suggested atomic in the other email, did you abandon that idea?
>>
>
> No, if we have byte-wise atomic copy, I'd still use that, but that is
> not something already implemented in Rust. (my reply had a "if we want
> to avoid implementing something by ourselves" at last)

Got it.

>
>> > so we may have to use `bindings::memcpy()` or
>> > core::intrinsics::volatile_copy_memory() [1]
>>
>> I was looking at this one, but it is unstable behind `core_intrinsics`.
>> I was uncertain about pulling in additional unstable features. This is
>
> That's also why I said "(or suggest Rust to stabilize something).
>
>> why I was looking for something in the C kernel to use.
>>
>> I think `bindings::memcpy` is not guaranteed to be implemented as inline
>> assembly, so it may not have volatile semantics?
>>
>
> Well, it's used in C as if it's volatile, for example, it's used in the
> similar case in bio_copy_data_iter() (hopefully you can confirm that's
> indeed a similar case).

Yes, this is the exact same situation. It is used higher in the stack,
but same constraints.

> And I'm suggesting we use it forever, just use
> it while waiting for volatile_copy_memory() or something.

Ok, I'm fine with that. We can use this one and add a TODO note.


Best regards,
Andreas Hindborg