[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0bff87e4-30cf-497d-8c50-a3469b4ec535@gmail.com>
Date: Mon, 17 Mar 2025 20:51:55 +0200
From: Abdiel Janulgue <abdiel.janulgue@...il.com>
To: Benno Lossin <benno.lossin@...ton.me>, Boqun Feng <boqun.feng@...il.com>
Cc: rust-for-linux@...r.kernel.org, daniel.almeida@...labora.com,
dakr@...nel.org, robin.murphy@....com, aliceryhl@...gle.com,
Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
Gary Guo <gary@...yguo.net>, Björn Roy Baron
<bjorn3_gh@...tonmail.com>, Andreas Hindborg <a.hindborg@...nel.org>,
Trevor Gross <tmgross@...ch.edu>, Valentin Obst <kernel@...entinobst.de>,
open list <linux-kernel@...r.kernel.org>, Christoph Hellwig <hch@....de>,
Marek Szyprowski <m.szyprowski@...sung.com>, airlied@...hat.com,
"open list:DMA MAPPING HELPERS" <iommu@...ts.linux.dev>
Subject: Re: [PATCH v14 02/11] rust: add dma coherent allocator abstraction.
On 11/03/2025 23:34, Benno Lossin wrote:
> On Tue Mar 11, 2025 at 7:12 PM CET, Boqun Feng wrote:
>> On Tue, Mar 11, 2025 at 07:47:58PM +0200, Abdiel Janulgue wrote:
>> [...]
>>> + /// Reads the value of `field` and ensures that its type is [`FromBytes`].
>>> + ///
>>> + /// # Safety
>>> + ///
>>> + /// This must be called from the [`dma_read`] macro which ensures that the `field` pointer is
>>> + /// validated beforehand.
>>> + ///
>>> + /// Public but hidden since it should only be used from [`dma_read`] macro.
>>> + #[doc(hidden)]
>>> + pub unsafe fn field_read<F: FromBytes>(&self, field: *const F) -> F {
>>> + // SAFETY: By the safety requirements field is valid.
>>> + unsafe { field.read_volatile() }
>>
>> I agree with Andreas that we should document the exception of usage on
>> {read,write}_volatile() here. How about:
>>
>> When dealing with a potential race from a hardware or code outside
>> kernel (e.g. user-space program), we need that read and write on a valid
>> memory are not UBs. Currently {read,write}_volatile() are used for this,
>
> I would use the singular `UB` here and below.
>
>> and the rationale behind is that they should generate the same code as
>> READ_ONCE() and WRITE_ONCE() which kernel already relies on to avoid UBs
>
> s/kernel/the kernel/
>
>> on data races. Note that the usage of {read,write}_volatile() is limited
>> to this particular case, they cannot be used to emit the UBs caused by
>
> s/emit/prevent/
>
>> racing between two kernel functions nor do they provide atomicity.
>>
>> Thoughts? One problem is that I don't know where to put this document
>> :-( Any suggestion?
>
> I am a bit out of the loop on this one, but why not put into the safety
> comment? I.e. explicitly state that this is *not* sound as per the usual
> rules and it is a special exception?
>
Thanks for this! I've incorporated the comments in v15
/Abdiel
Powered by blists - more mailing lists