linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andreas Hindborg <a.hindborg@kernel.org>
Cc: "Alice Ryhl" <aliceryhl@google.com>,
	"Boqun Feng" <boqun@kernel.org>,
	"Greg KH" <gregkh@linuxfoundation.org>,
	"Lorenzo Stoakes" <lorenzo.stoakes@oracle.com>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Will Deacon" <will@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	linux-mm@kvack.org, rust-for-linux@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] rust: page: add byte-wise atomic memory copy methods
Date: Tue, 17 Feb 2026 17:04:51 +0100	[thread overview]
Message-ID: <20260217160451.GA2995752@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <87ecmjcw2v.fsf@kernel.org>

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

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

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.

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

I've heard it said that in Scottish 'fucking' is the mere announcement
of a noun.

> I would suggest that if we are failing to understand each other, or if
> we are miscommunicating, let's be curious instead of angry. It get's us
> to where we want to be, way faster. And it is a much more pleasant
> journey.

/me mumbles something and quickly drops the mic before the PC police get
here...


  reply	other threads:[~2026-02-17 16:05 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-12 14:51 Andreas Hindborg
2026-02-12 16:41 ` Boqun Feng
2026-02-12 17:10   ` Andreas Hindborg
2026-02-12 17:23     ` Andreas Hindborg
2026-02-13  9:55 ` Peter Zijlstra
2026-02-13 12:18   ` Greg KH
2026-02-13 12:58     ` Andreas Hindborg
2026-02-13 13:20       ` Greg KH
2026-02-13 14:13         ` Andreas Hindborg
2026-02-13 14:26           ` Peter Zijlstra
2026-02-13 15:34             ` Greg KH
2026-02-13 15:45               ` Boqun Feng
2026-02-13 15:58                 ` Greg KH
2026-02-13 16:19                   ` Boqun Feng
2026-02-17  9:13                     ` Peter Zijlstra
2026-02-17  9:33                       ` Alice Ryhl
2026-02-17  9:45                         ` Peter Zijlstra
2026-02-17 10:01                           ` Alice Ryhl
2026-02-17 10:25                             ` Peter Zijlstra
2026-02-17 10:47                               ` Alice Ryhl
2026-02-17 11:09                                 ` Peter Zijlstra
2026-02-17 11:51                                   ` Alice Ryhl
2026-02-17 12:09                                     ` Peter Zijlstra
2026-02-17 13:00                                       ` Peter Zijlstra
2026-02-17 13:54                                         ` Danilo Krummrich
2026-02-17 15:50                                           ` Peter Zijlstra
2026-02-17 16:10                                             ` Danilo Krummrich
2026-02-17 13:09                                       ` Alice Ryhl
2026-02-17 15:48                                         ` Peter Zijlstra
2026-02-17 23:39                                           ` Gary Guo
2026-02-18  8:37                                             ` Peter Zijlstra
2026-02-18  9:31                                               ` Alice Ryhl
2026-02-18 10:09                                                 ` Peter Zijlstra
2026-02-17 13:56                                     ` Andreas Hindborg
2026-02-17 16:04                                       ` Peter Zijlstra [this message]
2026-02-17 18:43                                         ` Andreas Hindborg
2026-02-17 20:32                                           ` Jens Axboe
2026-02-17 15:52                       ` Boqun Feng
2026-02-17  9:17                 ` Peter Zijlstra
2026-02-17  9:23                   ` Peter Zijlstra
2026-02-17  9:37                     ` Alice Ryhl
2026-02-17 10:01                       ` Peter Zijlstra
2026-02-17  9:33                   ` Peter Zijlstra
2026-02-14  0:07               ` Gary Guo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260217160451.GA2995752@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=a.hindborg@kernel.org \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=boqun@kernel.org \
    --cc=dakr@kernel.org \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=lossin@kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox