From: Boqun Feng <boqun.feng@gmail.com>
To: comex <comexk@gmail.com>
Cc: "Ralf Jung" <post@ralfj.de>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Abdiel Janulgue" <abdiel.janulgue@gmail.com>,
dakr@kernel.org, robin.murphy@arm.com,
rust-for-linux@vger.kernel.org, "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Trevor Gross" <tmgross@umich.edu>,
"Valentin Obst" <kernel@valentinobst.de>,
linux-kernel@vger.kernel.org, "Christoph Hellwig" <hch@lst.de>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
airlied@redhat.com, iommu@lists.linux.dev, lkmm@lists.linux.dev
Subject: Re: Allow data races on some read/write operations
Date: Tue, 4 Mar 2025 19:24:11 -0800 [thread overview]
Message-ID: <hkhgihg4fjkg7zleqnumuj65dfvmxa5rzawkiafrf4kn5ss6nw@o7kc6xe2bmuj> (raw)
In-Reply-To: <88456D33-C5CA-4F4F-990E-8C5F2AF7EAF9@gmail.com>
On Tue, Mar 04, 2025 at 12:18:28PM -0800, comex wrote:
>
> > On Mar 4, 2025, at 11:03 AM, Ralf Jung <post@ralfj.de> wrote:
> >
> > Those already exist in Rust, albeit only unstably:
> > <https://doc.rust-lang.org/nightly/std/intrinsics/fn.volatile_copy_memory.html>.
> > However, I am not sure how you'd even generate such a call in C? The
> > standard memcpy function is not doing volatile accesses, to my
> > knowledge.
>
> The actual memcpy symbol that exists at runtime is written in
> assembly, and should be valid to treat as performing volatile
> accesses.
>
> But both GCC and Clang special-case the memcpy function. For example,
> if you call memcpy with a small constant as the size, the optimizer
> will transform the call into one or more regular loads/stores, which
> can then be optimized mostly like any other loads/stores (except for
> opting out of alignment and type-based aliasing assumptions). Even if
> the call isn’t transformed, the optimizer will still make assumptions.
> LLVM will automatically mark memcpy `nosync`, which makes it undefined
> behavior if the function “communicate[s] (synchronize[s]) with another
> thread”, including through “volatile accesses”. [1]
>
> However, these optimizations should rarely trigger misbehavior in
> practice, so I wouldn’t be surprised if Linux had some code that
> expected memcpy to act volatile…
>
Also in this particular case we are discussing [1], it's a memcpy (from
or to) a DMA buffer, which means the device can also read or write the
memory, therefore the content of the memory may be altered outside the
program (the kernel), so we cannot use copy_nonoverlapping() I believe.
[1]: https://lore.kernel.org/rust-for-linux/87bjuil15w.fsf@kernel.org/
Regards,
Boqun
> But I’m not familiar enough with the codebase to know whether such
> code actually exists, or where.
>
> (Incidentally, there is a compiler flag to turn the memcpy
> special-casing off, -fno-builtin. I pretty much expected that Linux
> used it. But I just checked, and it doesn’t.)
>
> For Rust, I don’t know why we haven’t exposed volatile_copy_memory
> yet. All I can find are some years-old discussions with no obvious
> blockers. I guess nobody has cared enough. There is also a somewhat
> stagnant RFC for *atomic* memcpy. [2]
>
> [1] https://llvm.org/docs/LangRef.html, search for 'nosync'
> [2] https://github.com/rust-lang/rfcs/pull/3301
>
next prev parent reply other threads:[~2025-03-05 3:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <6dea7b6a-1534-47e7-94d2-d67417c3d4c1@proton.me>
[not found] ` <tnwDK3QN_Xr0Yoa3U8HVxS5OqjvxIhgmmO_ifTGJR_EtIzjoxawOHtnbOJ9yChsUWXyFPcU9beIdrgbpfGZI8w==@protonmail.internalid>
[not found] ` <3202F69F-397E-4BC4-8DD8-E2D4B0AB056F@collabora.com>
[not found] ` <87bjuil15w.fsf@kernel.org>
[not found] ` <t4HxdvR7WBX_861hiTXo72jqC9F9oRpIzgA_dD2yhcSuLISEkC-shMfSgllrFPpnkSZXGfRcc47keudMooNiIQ==@protonmail.internalid>
[not found] ` <CAH5fLgg5MuUu=TX8mMsPf5RcLhMLHSU4Vct=h8rFX6Z7HjPxeA@mail.gmail.com>
[not found] ` <87ikoqjg1n.fsf@kernel.org>
[not found] ` <KpWTCfIlcLYFBpSvWPfALJ9VQn5a99_RAvxgMBc1aCrSalPB-qaW9IhXyaDG7HM1AcFPX5chj_Yr7IQp3F7UqA==@protonmail.internalid>
[not found] ` <CAH5fLgh6ubawHh76wq7JPbcuBCWhm91m7Rc01MVsX-a3C6qaVA@mail.gmail.com>
[not found] ` <87mse2hrd8.fsf@kernel.org>
2025-03-03 20:08 ` Allow data races on some read/write operations Boqun Feng
2025-03-04 19:03 ` Ralf Jung
2025-03-04 20:18 ` comex
2025-03-05 3:24 ` Boqun Feng [this message]
2025-03-05 13:10 ` Ralf Jung
2025-03-05 13:23 ` Alice Ryhl
2025-03-05 13:27 ` Ralf Jung
2025-03-05 14:40 ` Robin Murphy
2025-03-05 18:43 ` Andreas Hindborg
2025-03-05 19:30 ` Alan Stern
2025-03-05 19:42 ` Ralf Jung
2025-03-05 21:26 ` Andreas Hindborg
2025-03-05 21:53 ` Ralf Jung
2025-03-07 8:43 ` Andreas Hindborg
2025-03-18 14:44 ` Ralf Jung
2025-03-05 18:41 ` Andreas Hindborg
2025-03-05 14:25 ` Daniel Almeida
2025-03-05 18:38 ` Andreas Hindborg
2025-03-05 22:01 ` Ralf Jung
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=hkhgihg4fjkg7zleqnumuj65dfvmxa5rzawkiafrf4kn5ss6nw@o7kc6xe2bmuj \
--to=boqun.feng@gmail.com \
--cc=a.hindborg@kernel.org \
--cc=abdiel.janulgue@gmail.com \
--cc=airlied@redhat.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=comexk@gmail.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=gary@garyguo.net \
--cc=hch@lst.de \
--cc=iommu@lists.linux.dev \
--cc=kernel@valentinobst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=lkmm@lists.linux.dev \
--cc=m.szyprowski@samsung.com \
--cc=ojeda@kernel.org \
--cc=post@ralfj.de \
--cc=robin.murphy@arm.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).