Rust for Linux List
 help / color / mirror / Atom feed
From: "Danilo Krummrich" <dakr@kernel.org>
To: "Gary Guo" <gary@garyguo.net>
Cc: "Alexandre Courbot" <acourbot@nvidia.com>,
	git@younes.io, "Abdiel Janulgue" <abdiel.janulgue@gmail.com>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Robin Murphy" <robin.murphy@arm.com>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Tamir Duberstein" <tamird@kernel.org>,
	"Onur Özkan" <work@onurozkan.dev>,
	"Timur Tabi" <ttabi@nvidia.com>,
	driver-core@lists.linux.dev, rust-for-linux@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rust: dma: return zero for Coherent reads past EOF
Date: Fri, 24 Jul 2026 03:22:25 +0200	[thread overview]
Message-ID: <DK6EP5W2N2U5.OTWCUSAPJWFD@kernel.org> (raw)
In-Reply-To: <DK6DXU51V88J.23CVF9ARSSGT2@garyguo.net>

On Fri Jul 24, 2026 at 2:46 AM CEST, Gary Guo wrote:
> On Fri Jul 24, 2026 at 1:18 AM BST, Alexandre Courbot wrote:
>> On Fri Jul 24, 2026 at 8:32 AM JST, Gary Guo wrote:
>>> On Mon Jul 20, 2026 at 8:21 PM BST, Younes Akhouayri via B4 Relay wrote:
>>>> From: Younes Akhouayri <git@younes.io>
>>>>
>>>> Coherent<T>::write_to_slice() calculates a zero-byte copy when the file
>>>> offset is beyond the allocation, but still calls
>>>> UserSliceWriter::write_dma(). The latter rejects offsets beyond the
>>>> allocation even when the copy length is zero, so a debugfs read past EOF
>>>> returns -ERANGE.
>>>>
>>>> Return before calling write_dma() when the offset is at or beyond the
>>>> allocation, matching simple_read_from_buffer() EOF semantics.
>>>>
>>>> Fixes: 016818513936 ("rust: dma: implement BinaryWriter for Coherent<[u8]>")
>>>> Signed-off-by: Younes Akhouayri <git@younes.io>
>>>> ---
>>>>  rust/kernel/dma.rs | 4 ++++
>>>>  1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/rust/kernel/dma.rs b/rust/kernel/dma.rs
>>>> index 200def84fb69..36b72fb9ab46 100644
>>>> --- a/rust/kernel/dma.rs
>>>> +++ b/rust/kernel/dma.rs
>>>> @@ -1005,6 +1005,10 @@ fn write_to_slice(
>>>>              return Ok(0);
>>>>          };
>>>>  
>>>> +        if offset_val >= self.size() {
>>>> +            return Ok(0);
>>>> +        }
>>>> +
>>>>          let count = self.size().saturating_sub(offset_val).min(writer.len());
>>>
>>> This saturating_sub is redundant now and should just use -.
>>
>> Or even better, you could use `checked_sub` to perform the test and the
>> subtraction in one go, while avoiding potentially panicking operands.
>
> I think the code is clearer with separate EOF check length calc. This also needs
> to return `Ok` so it's not like that you can use `?`.

At a first glance I also thought of checked_sub(), and I think

	let Some(count) = self.size().checked_sub(offset_val) else {
	    return Ok(0);
	};

	writer.write_dma(self, offset_val, count.min(writer.len()))?;

would work perfectly fine, but compared to Gary's proposal it still calls
write_dma() for offset_val == self.size(), which is harmless but unnecessary.

Another option to avoid the panicking operand would be to keep saturating_sub()
and add the check below the existing saturating_sub() call.

	if count == 0 {
	    return Ok(0);
	}

But this is also less obvious, as it hides a bit the fact that the problem is
about offset_val when calling write_dma().

So, I think using the potentially panicking operand is probably the best option,
but I'd also be fine taking the patch as it is.

  parent reply	other threads:[~2026-07-24  1:22 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20 19:21 [PATCH] rust: dma: return zero for Coherent reads past EOF Younes Akhouayri via B4 Relay
2026-07-23 16:15 ` Miguel Ojeda
2026-07-23 23:32 ` Gary Guo
2026-07-24  0:18   ` Alexandre Courbot
2026-07-24  0:46     ` Gary Guo
2026-07-24  1:19       ` Alexandre Courbot
2026-07-24  2:12         ` Gary Guo
2026-07-24  1:22       ` Danilo Krummrich [this message]
2026-07-24  5:14         ` Alexandre Courbot

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=DK6EP5W2N2U5.OTWCUSAPJWFD@kernel.org \
    --to=dakr@kernel.org \
    --cc=a.hindborg@kernel.org \
    --cc=abdiel.janulgue@gmail.com \
    --cc=acourbot@nvidia.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=driver-core@lists.linux.dev \
    --cc=gary@garyguo.net \
    --cc=git@younes.io \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tamird@kernel.org \
    --cc=tmgross@umich.edu \
    --cc=ttabi@nvidia.com \
    --cc=work@onurozkan.dev \
    /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