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

["Danilo Krummrich" <dakr@kernel.org>]

On Tue Feb 17, 2026 at 4:50 PM CET, Peter Zijlstra wrote:
> On Tue, Feb 17, 2026 at 02:54:30PM +0100, Danilo Krummrich wrote:
>> On Tue Feb 17, 2026 at 2:00 PM CET, Peter Zijlstra wrote:
>> > Anyway, I don't think something like the below is an unreasonable patch.
>> >
>> > It ensures all accesses to the ptr obtained from kmap_local_*() and
>> > released by kunmap_local() stays inside those two.
>> 
>> I'd argue that not ensuring this is a feature, as I don't see why we would want
>> to ensure this if !CONFIG_HIGHMEM.
>
> Because of the principle of least surprise. For the HIGHMEM case 'ptr'
> only lives between kmap and kunmap and any access must necessarily be
> confined in between those. Having the code behave differently for
> !HIGHMEM is surprising.

Well, I'd argue that those are two different things.

I agree that correct code does only ever access the pointer between kmap and
kunmap (and in Rust we could even enforce this at compile time through the type
system).

But the memory barrier is not required, i.e. if the compiler reorders things if
!CONFIG_HIGHMEM, that's fine.

I think it would be wrong if users would - for their code - rely on
"kunmap_local() already issues a memory barrier for me". It's an implementation
detail that depends on CONFIG_HIGHMEM, not an API guarantee.

>> I think this is not about not escaping a critical scope, but about ensuring to
>> read exactly once.
>
> It ends up being the same thing.

Reading a value multiple times within a certain scope and reading it exactly
once is a difference, no?