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

"Eliot Courtney" <[email protected]>
Newsgroups org.kernel.vger.rust-for-linux,dev.linux.lists.nova-gpu,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
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/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.