Re: [PATCH v8 09/12] rust: bitmap: add contiguous area operations

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Overly strict bounds check in `next_zero_area_off` causes unwarranted panics for valid edge cases when `CONFIG_RUST_BITMAP_HARDENED` is enabled.
--

commit 9d58aea77dca5a824882cabebc4724be42a07915
Author: Eliot Courtney <ecourtney@nvidia.com>

rust: bitmap: add contiguous area operations

This commit introduces bindings for contiguous area operations on bitmaps,
specifically next_zero_area_off(), next_zero_area(), set(), and clear().
It adds safety bounds checking that can be hardened via
CONFIG_RUST_BITMAP_HARDENED, along with KUnit tests for these operations.

> diff --git a/rust/kernel/bitmap.rs b/rust/kernel/bitmap.rs
> index df5505ec7a965..23c2b43a98acf 100644
> --- a/rust/kernel/bitmap.rs
> +++ b/rust/kernel/bitmap.rs

[ ... ]

> @@ -525,13 +529,159 @@ pub fn next_zero_bit(&self, start: usize) -> Option<usize> {
>              Some(index)
>          }
>      }
> +
> +    /// Finds a contiguous area of `nbits` zero bits at or after `start`, where the area plus
> +    /// `align_offset` is aligned to `align`.
> +    ///
> +    /// Returns the bit index of the start of the area, or [`None`] if no such area fitting in
> +    /// the bitmap exists.
> +    ///
> +    /// The returned index plus `align_offset` is a multiple of `align`.
> +    ///
> +    /// # Panics
> +    ///
> +    /// Panics if CONFIG_RUST_BITMAP_HARDENED is enabled and `start` is out of bounds.
> +    #[inline]
> +    pub fn next_zero_area_off(
> +        &self,
> +        start: usize,
> +        nbits: NonZero<usize>,
> +        align: Alignment,
> +        align_offset: usize,
> +    ) -> Option<usize> {
> +        bitmap_assert!(
> +            start < self.len(),
> +            "`start` must be < {}, was {}",
> +            self.len(),
> +            start
> +        );

[Severity: Medium]
When CONFIG_RUST_BITMAP_HARDENED is enabled, does this overly strict bounds
check cause unwarranted panics for valid edge cases?

Calling next_zero_area_off() (or its wrapper next_zero_area()) on an empty
BitmapVec (length 0) will panic immediately because 0 < 0 is false.
Additionally, standard iteration loops that update start to area_start + nbits
will panic on their final check if the previous area ended exactly at the
bitmap boundary (start == self.len()).

The underlying C implementation bitmap_find_next_zero_area_off() safely
handles start >= self.len() and returns an out-of-bounds index, which this
Rust wrapper correctly turns into a None return. Could this assertion be
relaxed to start <= self.len() to avoid these spurious panics?

> +
> +        let nr = u32::try_from(nbits.get()).ok()?;
> +        let align_mask = align.as_usize() - 1;

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260827-chid-v8-0-bc74c77d0214@nvidia.com?part=9