From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3A5D916DC12; Wed, 5 Mar 2025 18:41:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741200104; cv=none; b=alCN+5FU4/ORm+K/tOpT1hVILRck6vxPxXFPBWTk4WbZJIwY/aX20WToRZ8SEp+4EA/D/kfRA08Tc+xX2jz4Ie7321d8wplVQkVi3ubABD5439QQulnOBu+uZ7Fm5m4KSArJHVXZuV1gpxax1NRTH2BF2dOqbC4Tqsts9yG9gwc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741200104; c=relaxed/simple; bh=jrTF4JMcaFmMJw5i9Y0SheL3I3+C988b/8M3zT7DPQQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=KC8fjnzOseEjWh70fU2YSDR/0Eg1Cg2NcgQbWlyUtpMSNcHO1zSIBMCU8QFbNUX4e8VRBW0IwEpw8iIRCQ8c3eNx+a1llskxtmZselY9Rg0zV5Uu3KZruFwionzbTZvTbiWZ/3dXqCsEhAgZHnMASvXXVUavSimDP4kCYg1OTB4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=quE/LTeX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="quE/LTeX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4A491C4CED1; Wed, 5 Mar 2025 18:41:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1741200103; bh=jrTF4JMcaFmMJw5i9Y0SheL3I3+C988b/8M3zT7DPQQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=quE/LTeXSwhUffGGAzooZ1Yl/ZraoMBEHvZ8jjPjn/FCnwQue38yuTstJRn6s3Qaw q7IYjHDop4LrJ7b4gqOOEc5jBjHU2qHiaJ3UScJInIt3p44P65C+rtC1qziO4d5dXY bt6bUvqAqw2OL+PNvOuPPg1W4ettR23PdU6lCiOmaaKUncfzwPZ8f64VLj9l2LlkrE 7C82peiCumji0FLb5M3vHYP4UDMCGZwZIYob/gVIsGq5pV15b9N/D18sqLZnYe3nqP tikuzsuJZmnIqe4aGakZudz7foF1QaH0A3cvMLGTOLHH6jtaR8td/9out/BGLf2Bgs p8LJOj+56FqMw== From: Andreas Hindborg To: "Alice Ryhl" Cc: "Ralf Jung" , "Boqun Feng" , "comex" , "Daniel Almeida" , "Benno Lossin" , "Abdiel Janulgue" , , , , "Miguel Ojeda" , "Alex Gaynor" , "Gary Guo" , =?utf-8?Q?Bj=C3=B6rn?= Roy Baron , "Trevor Gross" , "Valentin Obst" , , "Christoph Hellwig" , "Marek Szyprowski" , , , Subject: Re: Allow data races on some read/write operations In-Reply-To: (Alice Ryhl's message of "Wed, 05 Mar 2025 14:23:02 +0100") References: <87bjuil15w.fsf@kernel.org> <87ikoqjg1n.fsf@kernel.org> <87mse2hrd8.fsf@kernel.org> <88456D33-C5CA-4F4F-990E-8C5F2AF7EAF9@gmail.com> <25e7e425-ae72-4370-ae95-958882a07df9@ralfj.de> User-Agent: mu4e 1.12.7; emacs 29.4 Date: Wed, 05 Mar 2025 19:41:34 +0100 Message-ID: <87jz93721t.fsf@kernel.org> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "Alice Ryhl" writes: > On Wed, Mar 5, 2025 at 2:10=E2=80=AFPM Ralf Jung wrote: >> >> Hi, >> >> On 05.03.25 04:24, Boqun Feng wrote: >> > On Tue, Mar 04, 2025 at 12:18:28PM -0800, comex wrote: >> >> >> >>> On Mar 4, 2025, at 11:03=E2=80=AFAM, Ralf Jung wrote: >> >> However, these optimizations should rarely trigger misbehavior in >> >> practice, so I wouldn=E2=80=99t be surprised if Linux had some code t= hat >> >> expected memcpy to act volatile=E2=80=A6 >> >> >> > >> > 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/ >> >> Is there actually a potential for races (with reads by hardware, not oth= er >> threads) on the memcpy'd memory? Or is this the pattern where you copy s= ome data >> somewhere and then set a flag in an MMIO register to indicate that the d= ata is >> ready and the device can start reading it? In the latter case, the actua= l data >> copy does not race with anything, so it can be a regular non-atomic non-= volatile >> memcpy. The flag write *should* be a release write, and release volatile= writes >> do not exist, so that is a problem, but it's a separate problem from vol= atile >> memcpy. One can use a release fence followed by a relaxed write instead. >> Volatile writes do not currently act like relaxed writes, but you need t= hat >> anyway for WRITE_ONCE to make sense so it seems fine to rely on that her= e as well. >> >> Rust should have atomic volatile accesses, and various ideas have been p= roposed >> over the years, but sadly nobody has shown up to try and push this throu= gh. >> >> If the memcpy itself can indeed race, you need an atomic volatile memcpy= -- >> which neither C nor Rust have, though there are proposals for atomic mem= cpy (and >> arguably, there should be a way to interact with a device using non-vola= tile >> atomics... but anyway in the LKMM, atomics are modeled with volatile, so= things >> are even more entangled than usual ;). > > For some kinds of hardware, we might not want to trust the hardware. > I.e., there is no race under normal operation, but the hardware could > have a bug or be malicious and we might not want that to result in UB. > This is pretty similar to syscalls that take a pointer into userspace > memory and read it - userspace shouldn't modify that memory during the > syscall, but it can and if it does, that should be well-defined. > (Though in the case of userspace, the copy happens in asm since it > also needs to deal with virtual memory and so on.) Could you point me to this code? As mentioned in a parallel email in this thread, zero copy file i/o has this property. User space pages are mapped into the kernel and read from / written to. C just calls `memcpy` for this. Best regards, Andreas Hindborg