[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <DDZZX8AJKTP3.2OTD2L9ULVUG0@kernel.org>
Date: Tue, 04 Nov 2025 15:55:51 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Alice Ryhl" <aliceryhl@...gle.com>
Cc: <abdiel.janulgue@...il.com>, <daniel.almeida@...labora.com>,
<robin.murphy@....com>, <a.hindborg@...nel.org>, <ojeda@...nel.org>,
<alex.gaynor@...il.com>, <boqun.feng@...il.com>, <gary@...yguo.net>,
<bjorn3_gh@...tonmail.com>, <lossin@...nel.org>, <tmgross@...ch.edu>,
<linux-kernel@...r.kernel.org>, <rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH 1/2] rust: dma: make use of start_ptr() and
start_ptr_mut()
On Tue Nov 4, 2025 at 3:31 PM CET, Alice Ryhl wrote:
> On Tue, Nov 04, 2025 at 10:13:08AM +0100, Danilo Krummrich wrote:
>> On 11/4/25 9:39 AM, Alice Ryhl wrote:
>> > On Mon, Nov 03, 2025 at 08:06:49PM +0100, Danilo Krummrich wrote:
>> >> Using start_ptr() and start_ptr_mut() has the advantage that we inherit
>> >> the requirements the a mutable or immutable reference from those
>> >> methods.
>> >>
>> >> Hence, use them instead of self.cpu_addr.
>> >>
>> >> Signed-off-by: Danilo Krummrich <dakr@...nel.org>
>> >
>> >> // and we've just checked that the range and index is within bounds.
>> >> // - `offset` can't overflow since it is smaller than `self.count` and we've checked
>> >> // that `self.count` won't overflow early in the constructor.
>> >> - Ok(unsafe { self.cpu_addr.add(offset) })
>> >> + Ok(unsafe { self.start_ptr().cast_mut().add(offset) })
>> >
>> > I guess this shows that the mutable/immutable requirements we inherit
>> > aren't actually what we need?
>>
>> item_from_index() is used for the dma_read!() and dma_write!() macros, hence
>> this one is on purpose.
>
> I guess it's more that you don't really need mutable access to call
> start_ptr_mut() for this particular case?
In general I think it's good to require a mutable reference for start_ptr_mut(),
as in the absolute majority of cases we actually want to inherit exclusive
access.
As you say, in this particular case we do not want to inherit exclusive access
on purpose.
Powered by blists - more mailing lists