Re: [PATCH v7 02/10] rust: bitmap: restrict bitmap length to at most i32::MAX

["Eliot Courtney" <ecourtney@nvidia.com>]

On Fri Aug 21, 2026 at 4:37 PM JST, Alexandre Courbot wrote:
> On Mon Aug 17, 2026 at 4:04 PM JST, Eliot Courtney wrote:
>> It is currently possible to construct a non-`BitmapVec` backed
>> `Bitmap` using `Bitmap::from_raw` that is larger than `i32::MAX`, and
>> it is not part of the unsafe requirements. Restricting all bitmaps
>> (even non-`BitmapVec` backed ones) to a maximum size of `i32::MAX`
>> simplifies a few things and matches `BitmapVec::MAX_LEN`.
>
> Can we be more explicit (if possible in the doccomments as well) about
> what "a few things" is? IIUC we are doing this because some of the C
> APIs take an `int`, so we can just state that much.

Yeah, it somewhat depends on which version of the underlying C function
is being called. The exact details vary between drm-rust-next's version
and bitmap-for-next's version. Here is a (non-exhaustive?) list:

- `copy_and_extend` truncates `len` to u32, which is wrong for >
  u32::MAX size
- `__bitmap_set` and `__bitmap_clear` need i32 for size and u32 for
  start - so you couldn't run these on a `Bitmap` with a > i32::MAX
  size.
- `next_zero_area_off` on bitmap-for-next can overflow without this
  restriction (we still have some overflow cases even with this
  restriction on 32-bit, or through `align_offset` in general)

I'll add a note to the commit message and doccomment about the reasoning
which IMO should more be about keeping the set of invariants between
BitmapVec and Bitmap the same.

>
> Note also (as a point to consider, not a review ask) that we could
> enforce this requirement in the type system if we made `nbits` a
> `Bounded<usize, 31>`. Currently `from_raw` and `from_raw_mut` are
> unsafe, so this becomes one more invariant for the caller to uphold, but
> would we have made them unsafe just for this if they weren't already?

I heard from Yury [1] that there is some work to eventually unify on
unsigned longs. So I expect that the i32::MAX restriction may not be
around forever. That's why I didn't do a change like Bounded here cos
it's quite intrusive.

[1]: https://lore.kernel.org/all/anELwosZSI5MZR4d@yury/