Re: [PATCH v8 3/7] rust: dma: implement BinaryWriter for CoherentAllocation<u8>

["Alexandre Courbot" <acourbot@nvidia.com>]

On Mon Mar 16, 2026 at 3:57 AM JST, Timur Tabi wrote:
> On Sun, 2026-03-15 at 14:11 +0900, Alexandre Courbot wrote:
>> > Well, yes, but there's actually a bigger problem, now that you point this out.  If usize is
>> > 32
>> > bits, the try_into() could fail if *offset is too large.  In that case, it should return
>> > Ok(0)
>> > instead of EINVAL.
>> > 
>> > So actually, we need to keep the is_negative() check, but should modify the try_into() to
>> > return
>> > Ok(0) instead of EINVAL.
>> > 
>> > let Ok(offset_val) = usize::try_from(*offset) else {
>> >      return Ok(0);  // offset too large for usize = past EOF
>> > };
>> > 
>> > Are we going to assume CONFIG_64BIT forever, and just ignore any possible errors if usize is
>> > 32
>> > bits?
>> 
>> This is not Nova, so we cannot assume CONFIG_64BIT. I guess we have to
>> do as you described above.
>
> Yes, you're right.  I forgot that this was common code.  
>
> Still, I wonder.  It seems incongruous to me that, on a 32-bit platform, offsets (file::Offset)
> are 64-bit but sizes (usize) are only 32-bit. 

`file::Offset` maps to the C's `loff_t` which is a version of `off_t`
that is guaranteed to be 64-bit. The kernel core APIs (like
`file_operations` seem to all use `loff_t`, so it makes sense for Rust
to follow suit.

I suppose the kernel uses `loff_t` everywhere where files are involved
because without that it wouldn't be able to manage files larger than
2GB. With that in mind, the extra check when converting to a 32-bit
pointer makes more sense.