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

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

"Peter Zijlstra" <peterz@infradead.org> writes:

> On Tue, Feb 17, 2026 at 02:56:40PM +0100, Andreas Hindborg wrote:
>
>> I'm processing disk IO in the Rust null block driver. The pages backing
>> the IO requests may be simultaneously mapped to user space, so there is
>> no way to guarantee that there is no concurrent memory operation to/from
>> the memory area. User space programs can do whatever.
>>
>> I don't have any control flow depending on the data I copy. I just store
>> it somewhere and return it if a read IO for the same sector arrive.
>
> Right, so IIRC the old DIO code used to have this problem. We'd end up
> writing whatever random state to disk if you did DIO of an mmap().
>
> And if IIRC the current state of things is better in that we ensure the
> mapping becomes RO and we have writes fault and wait until the writeback
> is complete, ensuring things are somewhat more consistent.
>
> But you'd better ask Jens or someone that has looked at the various IO
> paths in the past 10 years or so :-)

Oh, this is a really important detail that I did not find while trying
to follow the code path from user space.

Cc: Jens Axboe <axboe@kernel.dk>

@Jens is this so, are pages from user space that are part of a write
request mapped RO during the IO operation?

>
>> Let me add a bit of context as to why I sent this patch. I am not an
>> expert on the finer details of this subject, so I rely on available
>> expertise in our community. It is my understanding that copying the
>> memory in the situation outlined above, without special consideration
>> (in Rust) would be undefined behavior. Such are the rules of the
>> language. Of course I don't want undefined behavior in the Rust null
>> block driver. When asked how to solve this, the experts suggested
>> defining this byte-wise atomic memory copy function, A function that
>> would have well defined behavior in this particular situation.
>
> Yeah, so being a C programmer, stepping in UB and tearing up the spec is
> what you do on the daily. Its called reality :-)

I see. From my observations, "Rust people" in general have a somewhat
different approach to UB. An approach where we avoid it. We would rather
fix the language so that we can do what we need to do, in a well defined
manner.

>
> In reality it is *really* hard to have memcpy() not be sane. And if the
> Rust spec doesn't outlaw out-of-thin-air, then the Rust spec is wrong.
> It really is that simple.

I'm at the far end of my knowledge here, but I believe that I read that
the theoretical model allows OOTA but that this is considered a bug of
the model. I'm not sure what to do with this information though.

>
>> That seems like a reasonable course of action to me. I don't understand
>> why this is such a big deal, and I don't understand the need to use
>> aggressive language and swearing.
>
> Feh, there hardly was any o that :-) Call it cultural differences and
> show how inclusive you are by being open to how other people have
> different norms, whahaha :-)

Touche.


Best regards,
Andreas Hindborg