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 <[email protected]> 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/[email protected]?part=9
