[PATCH 0/4] rust: Add support for reserving of ranges of IDs

[PATCH 0/4] rust: Add support for reserving of ranges of IDs

[Eliot Courtney]

Add support for reserving of ranges of IDs, with a usage in nova-core
for channel IDs. This entails adding the helpers+users of the C bitmap
API for ranges of bits, then users of that in `IdPool`, and finally a
user of `IdPool` in nova-core, `ChannelIdPool`.

This is based on drm-rust-next.

Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
---
Eliot Courtney (4):
      rust: bitmap: use function-level cfg on kunit test
      rust: bitmap: add contiguous area operations
      rust: id_pool: add contiguous area allocation
      gpu: nova-core: add ChannelIdPool

 drivers/gpu/nova-core/gpu.rs         |   2 +
 drivers/gpu/nova-core/gpu/channel.rs | 134 +++++++++++++++++++
 rust/helpers/bitmap.c                |  22 ++++
 rust/kernel/bitmap.rs                | 244 +++++++++++++++++++++++++++++++++--
 rust/kernel/id_pool.rs               |  68 ++++++++++
 5 files changed, 456 insertions(+), 14 deletions(-)
---
base-commit: a73a398a68ca9b9e5116a617562471f16b8310c4
change-id: 20260608-chid-18fa943c6d6c

Best regards,
--  
Eliot Courtney <ecourtney@nvidia.com>

[PATCH 1/4] rust: bitmap: use function-level cfg on kunit test

[Eliot Courtney]

Since commit c652dc44192d ("rust: kunit: allow `cfg` on `test`s"),
we no longer need this workaround.

Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
---
 rust/kernel/bitmap.rs | 25 +++++++++++--------------
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/rust/kernel/bitmap.rs b/rust/kernel/bitmap.rs
index b27e0ec80d64..a43bfe0ec3dc 100644
--- a/rust/kernel/bitmap.rs
+++ b/rust/kernel/bitmap.rs
@@ -572,24 +572,21 @@ fn bitmap_set_clear_find() -> Result<(), AllocError> {
     }
 
     #[test]
+    #[cfg(not(CONFIG_RUST_BITMAP_HARDENED))]
     fn owned_bitmap_out_of_bounds() -> Result<(), AllocError> {
-        // TODO: Kunit #[test]s do not support `cfg` yet,
-        // so we add it here in the body.
-        #[cfg(not(CONFIG_RUST_BITMAP_HARDENED))]
-        {
-            let mut b = BitmapVec::new(128, GFP_KERNEL)?;
-            b.set_bit(2048);
-            b.set_bit_atomic(2048);
-            b.clear_bit(2048);
-            b.clear_bit_atomic(2048);
-            assert_eq!(None, b.next_bit(2048));
-            assert_eq!(None, b.next_zero_bit(2048));
-            assert_eq!(None, b.last_bit());
-        }
+        let mut b = BitmapVec::new(128, GFP_KERNEL)?;
+
+        b.set_bit(2048);
+        b.set_bit_atomic(2048);
+        b.clear_bit(2048);
+        b.clear_bit_atomic(2048);
+        assert_eq!(None, b.next_bit(2048));
+        assert_eq!(None, b.next_zero_bit(2048));
+        assert_eq!(None, b.last_bit());
         Ok(())
     }
 
-    // TODO: uncomment once kunit supports [should_panic] and `cfg`.
+    // TODO: uncomment once kunit supports `#[should_panic]`.
     // #[cfg(CONFIG_RUST_BITMAP_HARDENED)]
     // #[test]
     // #[should_panic]

-- 
2.54.0

[PATCH 2/4] rust: bitmap: add contiguous area operations

[Eliot Courtney]

Add bindings and helpers for area operations on bitmaps. Each one is
made safe by adding some extra checks compared to the underlying C code
(for example, checking bounds) and with additional checks to catch
likely erroneous usage if `CONFIG_RUST_BITMAP_HARDENED` is on.

The C code uses signed integers for some parameters, for example the
length for `__bitmap_set`, so bounds check against i32::MAX. We can't
rely on `BitmapVec::MAX_LEN` because `Bitmap` may not necessarily be
backed by `BitmapVec`. There's also a few cases where a non power of two
minus one `align_mask` can cause an infinite loop in the C code (can
happen on overflow), so check for that.

Add tests demonstrating the edge cases.

Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
---
 rust/helpers/bitmap.c |  22 +++++
 rust/kernel/bitmap.rs | 219 ++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 241 insertions(+)

diff --git a/rust/helpers/bitmap.c b/rust/helpers/bitmap.c
index e4e9f4361270..dac5c03f2448 100644
--- a/rust/helpers/bitmap.c
+++ b/rust/helpers/bitmap.c
@@ -8,3 +8,25 @@ void rust_helper_bitmap_copy_and_extend(unsigned long *to, const unsigned long *
 {
 	bitmap_copy_and_extend(to, from, count, size);
 }
+
+__rust_helper
+unsigned long rust_helper_bitmap_find_next_zero_area(unsigned long *map,
+						     unsigned long size,
+						     unsigned long start,
+						     unsigned int nr,
+						     unsigned long align_mask)
+{
+	return bitmap_find_next_zero_area(map, size, start, nr, align_mask);
+}
+
+__rust_helper
+void rust_helper_bitmap_set(unsigned long *map, unsigned int start, unsigned int nbits)
+{
+	bitmap_set(map, start, nbits);
+}
+
+__rust_helper
+void rust_helper_bitmap_clear(unsigned long *map, unsigned int start, unsigned int nbits)
+{
+	bitmap_clear(map, start, nbits);
+}
diff --git a/rust/kernel/bitmap.rs b/rust/kernel/bitmap.rs
index a43bfe0ec3dc..f7290fa439d6 100644
--- a/rust/kernel/bitmap.rs
+++ b/rust/kernel/bitmap.rs
@@ -497,6 +497,129 @@ pub fn next_zero_bit(&self, start: usize) -> Option<usize> {
             Some(index)
         }
     }
+
+    /// Finds a contiguous area of `nbits` zero bits at or after `start`, aligned per `align_mask`.
+    ///
+    /// Returns the bit index of the start of the area, or [`None`] if no such area fitting in
+    /// the bitmap exists or the `align_mask` is invalid.
+    ///
+    /// `align_mask` should be `0` (no alignment) or one less than a power of two, in which case the
+    /// returned index is a multiple of that power of two.
+    ///
+    /// # Panics
+    ///
+    /// Panics if CONFIG_RUST_BITMAP_HARDENED is enabled and `start` is out of bounds or
+    /// `align_mask` is not `0` or `2^k - 1`.
+    ///
+    /// # Examples
+    ///
+    /// ```
+    /// use kernel::alloc::{AllocError, flags::GFP_KERNEL};
+    /// use kernel::bitmap::BitmapVec;
+    ///
+    /// let mut b = BitmapVec::new(64, GFP_KERNEL)?;
+    ///
+    /// assert_eq!(Some(0), b.next_zero_area(0, 8, 0));
+    /// b.set_area(0, 5);
+    /// assert_eq!(Some(5), b.next_zero_area(0, 8, 0));
+    /// assert_eq!(Some(8), b.next_zero_area(0, 8, 7));
+    /// assert_eq!(None, b.next_zero_area(0, 65, 0));
+    /// # Ok::<(), AllocError>(())
+    /// ```
+    #[inline]
+    pub fn next_zero_area(&self, start: usize, nbits: usize, align_mask: usize) -> Option<usize> {
+        bitmap_assert!(
+            start < self.len(),
+            "`start` must be < {}, was {}",
+            self.len(),
+            start
+        );
+
+        let valid_align_mask = align_mask
+            .checked_add(1)
+            .is_some_and(|p| p.is_power_of_two());
+
+        bitmap_assert!(
+            valid_align_mask,
+            "`align_mask` must be 0 or `2^k - 1`, was {}",
+            align_mask
+        );
+
+        if !valid_align_mask {
+            return None;
+        }
+
+        let nr = u32::try_from(nbits).ok()?;
+
+        // SAFETY: `bitmap_find_next_zero_area` is safe to use with an out of bounds `start` value,
+        // never reads beyond `self.len()` bits, and returns a value `>= self.len()` when no area is
+        // found.
+        let index = unsafe {
+            bindings::bitmap_find_next_zero_area(
+                self.as_ptr().cast_mut(),
+                self.len(),
+                start,
+                nr,
+                align_mask,
+            )
+        };
+
+        // In case of overflow, we may get back a range outside of what we requested.
+        let end = index.checked_add(nbits)?;
+        if index < start || index >= self.len() || end > self.len() {
+            None
+        } else {
+            Some(index)
+        }
+    }
+
+    /// Sets a contiguous area of `nbits` bits starting at `start`.
+    ///
+    /// If CONFIG_RUST_BITMAP_HARDENED is not enabled and the area `start..start + nbits` is out of
+    /// bounds, does nothing.
+    ///
+    /// # Panics
+    ///
+    /// Panics if CONFIG_RUST_BITMAP_HARDENED is enabled and the area `start..start + nbits` is out
+    /// of bounds.
+    #[inline]
+    pub fn set_area(&mut self, start: usize, nbits: usize) {
+        bitmap_assert_return!(
+            start
+                .checked_add(nbits)
+                .is_some_and(|end| end <= self.len() && end <= i32::MAX as usize),
+            "Area `start..start + nbits` ({}..{}) must be within bounds {}",
+            start,
+            start.saturating_add(nbits),
+            self.len()
+        );
+        // SAFETY: The area `start..start + nbits` is within bounds.
+        unsafe { bindings::bitmap_set(self.as_mut_ptr(), start as u32, nbits as u32) };
+    }
+
+    /// Clears a contiguous area of `nbits` bits starting at `start`.
+    ///
+    /// If CONFIG_RUST_BITMAP_HARDENED is not enabled and the area `start..start + nbits` is out of
+    /// bounds, does nothing.
+    ///
+    /// # Panics
+    ///
+    /// Panics if CONFIG_RUST_BITMAP_HARDENED is enabled and the area `start..start + nbits` is out
+    /// of bounds.
+    #[inline]
+    pub fn clear_area(&mut self, start: usize, nbits: usize) {
+        bitmap_assert_return!(
+            start
+                .checked_add(nbits)
+                .is_some_and(|end| end <= self.len() && end <= i32::MAX as usize),
+            "Area `start..start + nbits` ({}..{}) must be within bounds {}",
+            start,
+            start.saturating_add(nbits),
+            self.len()
+        );
+        // SAFETY: The area `start..start + nbits` is within bounds.
+        unsafe { bindings::bitmap_clear(self.as_mut_ptr(), start as u32, nbits as u32) };
+    }
 }
 
 #[cfg(CONFIG_RUST_BITMAP_KUNIT_TEST)]
@@ -614,4 +737,100 @@ fn bitmap_copy_and_extend() -> Result<(), AllocError> {
         assert_eq!(Some(17), long_bitmap.last_bit());
         Ok(())
     }
+
+    #[test]
+    fn bitmap_area_set_clear_find() -> Result<(), AllocError> {
+        let mut b = BitmapVec::new(128, GFP_KERNEL)?;
+
+        assert_eq!(Some(0), b.next_zero_area(0, 5, 0));
+        b.set_area(0, 5); // Now contains {[0, 5)}.
+
+        assert_eq!(Some(0), b.next_bit(0));
+        assert_eq!(Some(4), b.next_bit(4));
+        assert_eq!(Some(5), b.next_zero_bit(0));
+        assert_eq!(Some(5), b.next_zero_area(0, 5, 0));
+        assert_eq!(Some(8), b.next_zero_area(0, 5, 7));
+
+        b.set_area(8, 8); // Now contains {[0, 5), [8, 16)}.
+        assert_eq!(Some(16), b.next_zero_area(0, 4, 15));
+        assert_eq!(Some(16), b.next_zero_area(0, 4, 0));
+
+        b.clear_area(0, 5); // Now contains {[8, 16)}.
+        assert_eq!(Some(0), b.next_zero_area(0, 5, 0));
+        assert_eq!(Some(8), b.next_bit(0));
+        assert_eq!(Some(15), b.last_bit());
+
+        b.clear_area(16, 0); // Zero-length in-bounds clears are no-ops.
+        assert_eq!(Some(8), b.next_bit(0));
+        assert_eq!(Some(15), b.last_bit());
+
+        // A zero-length request returns the first aligned position at or
+        // after the next zero bit, even if that position's own bit is set.
+        assert_eq!(Some(1), b.next_zero_area(1, 0, 0));
+        assert_eq!(Some(8), b.next_zero_area(1, 0, 7));
+
+        b.set_area(60, 10); // Now contains {[8, 16), [60, 70)}.
+        assert_eq!(Some(60), b.next_bit(16));
+        assert_eq!(Some(69), b.last_bit());
+        assert_eq!(Some(16), b.next_zero_area(9, 40, 0));
+        assert_eq!(Some(70), b.next_zero_area(0, 45, 0));
+
+        b.clear_area(62, 6); // Now contains {[8, 16), [60, 62), [68, 70)}.
+        assert_eq!(Some(62), b.next_zero_area(60, 6, 0));
+        assert_eq!(Some(61), b.next_bit(61));
+        assert_eq!(Some(69), b.last_bit());
+
+        b.set_area(64, 0); // Zero-length in-bounds sets are no-ops.
+        assert_eq!(Some(62), b.next_zero_bit(62));
+        Ok(())
+    }
+
+    #[test]
+    fn bitmap_area_exhaustion() -> Result<(), AllocError> {
+        let mut b = BitmapVec::new(64, GFP_KERNEL)?;
+
+        assert_eq!(None, b.next_zero_area(0, 65, 0));
+        assert_eq!(None, b.next_zero_area(0, usize::MAX, 0));
+        assert_eq!(None, b.next_zero_area(1, usize::MAX, 0));
+
+        b.set_bit(0); // Now contains {[0, 1)}.
+        assert_eq!(None, b.next_zero_area(0, usize::MAX, 0));
+
+        b.set_area(0, 61); // Now contains {[0, 61)}.
+        assert_eq!(None, b.next_zero_area(0, 4, 0));
+        assert_eq!(Some(61), b.next_zero_area(0, 3, 0));
+        assert_eq!(None, b.next_zero_area(0, 1, 63));
+        Ok(())
+    }
+
+    #[test]
+    #[cfg(not(CONFIG_RUST_BITMAP_HARDENED))]
+    fn bitmap_area_invalid_align() -> Result<(), AllocError> {
+        let mut b = BitmapVec::new(64, GFP_KERNEL)?;
+        b.set_bit(0);
+
+        assert_eq!(Some(1), b.next_zero_bit(1));
+        // If this isn't rejected, it would cause a hang in the C code.
+        assert_eq!(None, b.next_zero_area(1, 1, usize::MAX));
+        // Reject non `2^k - 1` alignment masks.
+        assert_eq!(None, b.next_zero_area(1, 1, 2));
+        assert_eq!(None, b.next_zero_area(1, 1, 5));
+        Ok(())
+    }
+
+    #[test]
+    #[cfg(not(CONFIG_RUST_BITMAP_HARDENED))]
+    fn owned_bitmap_area_out_of_bounds() -> Result<(), AllocError> {
+        let mut b = BitmapVec::new(64, GFP_KERNEL)?;
+
+        // Should be ignored since out of bounds.
+        b.set_area(64, 4);
+        b.set_area(62, 8);
+        b.set_area(usize::MAX, 0);
+        b.clear_area(usize::MAX, 0);
+        b.clear_area(2048, 8);
+        assert_eq!(None, b.next_bit(0));
+        assert_eq!(None, b.next_zero_area(64, 1, 0));
+        Ok(())
+    }
 }

-- 
2.54.0

Re: [PATCH 2/4] rust: bitmap: add contiguous area operations

[Yury Norov]

On Fri, Jul 03, 2026 at 07:16:05PM +0900, Eliot Courtney wrote:
> Add bindings and helpers for area operations on bitmaps. Each one is
> made safe by adding some extra checks compared to the underlying C code
> (for example, checking bounds) and with additional checks to catch
> likely erroneous usage if `CONFIG_RUST_BITMAP_HARDENED` is on.
> 
> The C code uses signed integers for some parameters, for example the
> length for `__bitmap_set`, so bounds check against i32::MAX. We can't
> rely on `BitmapVec::MAX_LEN` because `Bitmap` may not necessarily be
> backed by `BitmapVec`. There's also a few cases where a non power of two
> minus one `align_mask` can cause an infinite loop in the C code (can
> happen on overflow), so check for that.
> 
> Add tests demonstrating the edge cases.
> 
> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
> ---
>  rust/helpers/bitmap.c |  22 +++++
>  rust/kernel/bitmap.rs | 219 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 241 insertions(+)
> 
> diff --git a/rust/helpers/bitmap.c b/rust/helpers/bitmap.c
> index e4e9f4361270..dac5c03f2448 100644
> --- a/rust/helpers/bitmap.c
> +++ b/rust/helpers/bitmap.c
> @@ -8,3 +8,25 @@ void rust_helper_bitmap_copy_and_extend(unsigned long *to, const unsigned long *
>  {
>  	bitmap_copy_and_extend(to, from, count, size);
>  }
> +
> +__rust_helper
> +unsigned long rust_helper_bitmap_find_next_zero_area(unsigned long *map,
> +						     unsigned long size,
> +						     unsigned long start,
> +						     unsigned int nr,
> +						     unsigned long align_mask)
> +{
> +	return bitmap_find_next_zero_area(map, size, start, nr, align_mask);
> +}
> +
> +__rust_helper
> +void rust_helper_bitmap_set(unsigned long *map, unsigned int start, unsigned int nbits)
> +{
> +	bitmap_set(map, start, nbits);
> +}
> +
> +__rust_helper
> +void rust_helper_bitmap_clear(unsigned long *map, unsigned int start, unsigned int nbits)
> +{
> +	bitmap_clear(map, start, nbits);
> +}

All three are the wrappers around the regular outline functions:
bitmap_find_next_zero_area_off(), __bitmap_set() and __bitmap_clear().

The inlined version in headers is optimized for small bitmaps. But the
optimization is all based on inlining in the C code. It doesn't work
if you wrap it with a rust helper.

There was a discussion about the similar find_next_bit(). The function
itself is an inliner, but it's a wrapper around the true outlined
_find_next_bit(). So we decided to minimize the binder size for that
type of functions.

Please, keep the binder minimal unless necessary.

> diff --git a/rust/kernel/bitmap.rs b/rust/kernel/bitmap.rs
> index a43bfe0ec3dc..f7290fa439d6 100644
> --- a/rust/kernel/bitmap.rs
> +++ b/rust/kernel/bitmap.rs
> @@ -497,6 +497,129 @@ pub fn next_zero_bit(&self, start: usize) -> Option<usize> {
>              Some(index)
>          }
>      }
> +
> +    /// Finds a contiguous area of `nbits` zero bits at or after `start`, aligned per `align_mask`.
> +    ///
> +    /// Returns the bit index of the start of the area, or [`None`] if no such area fitting in
> +    /// the bitmap exists or the `align_mask` is invalid.
> +    ///
> +    /// `align_mask` should be `0` (no alignment) or one less than a power of two, in which case the
> +    /// returned index is a multiple of that power of two.
> +    ///
> +    /// # Panics
> +    ///
> +    /// Panics if CONFIG_RUST_BITMAP_HARDENED is enabled and `start` is out of bounds or
> +    /// `align_mask` is not `0` or `2^k - 1`.
> +    ///
> +    /// # Examples
> +    ///
> +    /// ```
> +    /// use kernel::alloc::{AllocError, flags::GFP_KERNEL};
> +    /// use kernel::bitmap::BitmapVec;
> +    ///
> +    /// let mut b = BitmapVec::new(64, GFP_KERNEL)?;
> +    ///
> +    /// assert_eq!(Some(0), b.next_zero_area(0, 8, 0));
> +    /// b.set_area(0, 5);
> +    /// assert_eq!(Some(5), b.next_zero_area(0, 8, 0));
> +    /// assert_eq!(Some(8), b.next_zero_area(0, 8, 7));
> +    /// assert_eq!(None, b.next_zero_area(0, 65, 0));
> +    /// # Ok::<(), AllocError>(())
> +    /// ```
> +    #[inline]
> +    pub fn next_zero_area(&self, start: usize, nbits: usize, align_mask: usize) -> Option<usize> {
> +        bitmap_assert!(
> +            start < self.len(),
> +            "`start` must be < {}, was {}",
> +            self.len(),
> +            start
> +        );
> +
> +        let valid_align_mask = align_mask
> +            .checked_add(1)
> +            .is_some_and(|p| p.is_power_of_two());
> +
> +        bitmap_assert!(
> +            valid_align_mask,
> +            "`align_mask` must be 0 or `2^k - 1`, was {}",
> +            align_mask
> +        );
> +
> +        if !valid_align_mask {
> +            return None;
> +        }

This quite a trivial check takes about a half of the function in terms
of LOCs. Is there any way to compact it?

> +        let nr = u32::try_from(nbits).ok()?;
> +
> +        // SAFETY: `bitmap_find_next_zero_area` is safe to use with an out of bounds `start` value,
> +        // never reads beyond `self.len()` bits, and returns a value `>= self.len()` when no area is
> +        // found.
> +        let index = unsafe {
> +            bindings::bitmap_find_next_zero_area(
> +                self.as_ptr().cast_mut(),
> +                self.len(),
> +                start,
> +                nr,
> +                align_mask,
> +            )
> +        };
> +
> +        // In case of overflow, we may get back a range outside of what we requested.
> +        let end = index.checked_add(nbits)?;
> +        if index < start || index >= self.len() || end > self.len() {
> +            None
> +        } else {
> +            Some(index)
> +        }
> +    }
> +
> +    /// Sets a contiguous area of `nbits` bits starting at `start`.
> +    ///
> +    /// If CONFIG_RUST_BITMAP_HARDENED is not enabled and the area `start..start + nbits` is out of
> +    /// bounds, does nothing.
> +    ///
> +    /// # Panics
> +    ///
> +    /// Panics if CONFIG_RUST_BITMAP_HARDENED is enabled and the area `start..start + nbits` is out
> +    /// of bounds.
> +    #[inline]
> +    pub fn set_area(&mut self, start: usize, nbits: usize) {

Please don't invent new names. If this particular function in C is
named "bitmap_set()", it means that in rust world it should be
reflected with a method ".set()".

> +        bitmap_assert_return!(
> +            start
> +                .checked_add(nbits)
> +                .is_some_and(|end| end <= self.len() && end <= i32::MAX as usize),
> +            "Area `start..start + nbits` ({}..{}) must be within bounds {}",
> +            start,
> +            start.saturating_add(nbits),
> +            self.len()
> +        );
> +        // SAFETY: The area `start..start + nbits` is within bounds.
> +        unsafe { bindings::bitmap_set(self.as_mut_ptr(), start as u32, nbits as u32) };
> +    }
> +
> +    /// Clears a contiguous area of `nbits` bits starting at `start`.
> +    ///
> +    /// If CONFIG_RUST_BITMAP_HARDENED is not enabled and the area `start..start + nbits` is out of
> +    /// bounds, does nothing.
> +    ///
> +    /// # Panics
> +    ///
> +    /// Panics if CONFIG_RUST_BITMAP_HARDENED is enabled and the area `start..start + nbits` is out
> +    /// of bounds.
> +    #[inline]
> +    pub fn clear_area(&mut self, start: usize, nbits: usize) {

Same here: .clear(), please

> +        bitmap_assert_return!(
> +            start
> +                .checked_add(nbits)
> +                .is_some_and(|end| end <= self.len() && end <= i32::MAX as usize),
> +            "Area `start..start + nbits` ({}..{}) must be within bounds {}",
> +            start,
> +            start.saturating_add(nbits),
> +            self.len()
> +        );
> +        // SAFETY: The area `start..start + nbits` is within bounds.
> +        unsafe { bindings::bitmap_clear(self.as_mut_ptr(), start as u32, nbits as u32) };
> +    }
>  }
>  
>  #[cfg(CONFIG_RUST_BITMAP_KUNIT_TEST)]
> @@ -614,4 +737,100 @@ fn bitmap_copy_and_extend() -> Result<(), AllocError> {
>          assert_eq!(Some(17), long_bitmap.last_bit());
>          Ok(())
>      }
> +
> +    #[test]
> +    fn bitmap_area_set_clear_find() -> Result<(), AllocError> {
> +        let mut b = BitmapVec::new(128, GFP_KERNEL)?;
> +
> +        assert_eq!(Some(0), b.next_zero_area(0, 5, 0));
> +        b.set_area(0, 5); // Now contains {[0, 5)}.
> +
> +        assert_eq!(Some(0), b.next_bit(0));
> +        assert_eq!(Some(4), b.next_bit(4));
> +        assert_eq!(Some(5), b.next_zero_bit(0));
> +        assert_eq!(Some(5), b.next_zero_area(0, 5, 0));
> +        assert_eq!(Some(8), b.next_zero_area(0, 5, 7));
> +
> +        b.set_area(8, 8); // Now contains {[0, 5), [8, 16)}.
> +        assert_eq!(Some(16), b.next_zero_area(0, 4, 15));
> +        assert_eq!(Some(16), b.next_zero_area(0, 4, 0));
> +
> +        b.clear_area(0, 5); // Now contains {[8, 16)}.
> +        assert_eq!(Some(0), b.next_zero_area(0, 5, 0));
> +        assert_eq!(Some(8), b.next_bit(0));
> +        assert_eq!(Some(15), b.last_bit());
> +
> +        b.clear_area(16, 0); // Zero-length in-bounds clears are no-ops.
> +        assert_eq!(Some(8), b.next_bit(0));
> +        assert_eq!(Some(15), b.last_bit());
> +
> +        // A zero-length request returns the first aligned position at or
> +        // after the next zero bit, even if that position's own bit is set.
> +        assert_eq!(Some(1), b.next_zero_area(1, 0, 0));
> +        assert_eq!(Some(8), b.next_zero_area(1, 0, 7));
> +
> +        b.set_area(60, 10); // Now contains {[8, 16), [60, 70)}.
> +        assert_eq!(Some(60), b.next_bit(16));
> +        assert_eq!(Some(69), b.last_bit());
> +        assert_eq!(Some(16), b.next_zero_area(9, 40, 0));
> +        assert_eq!(Some(70), b.next_zero_area(0, 45, 0));
> +
> +        b.clear_area(62, 6); // Now contains {[8, 16), [60, 62), [68, 70)}.
> +        assert_eq!(Some(62), b.next_zero_area(60, 6, 0));
> +        assert_eq!(Some(61), b.next_bit(61));
> +        assert_eq!(Some(69), b.last_bit());
> +
> +        b.set_area(64, 0); // Zero-length in-bounds sets are no-ops.
> +        assert_eq!(Some(62), b.next_zero_bit(62));
> +        Ok(())
> +    }
> +
> +    #[test]
> +    fn bitmap_area_exhaustion() -> Result<(), AllocError> {
> +        let mut b = BitmapVec::new(64, GFP_KERNEL)?;
> +
> +        assert_eq!(None, b.next_zero_area(0, 65, 0));
> +        assert_eq!(None, b.next_zero_area(0, usize::MAX, 0));
> +        assert_eq!(None, b.next_zero_area(1, usize::MAX, 0));
> +
> +        b.set_bit(0); // Now contains {[0, 1)}.
> +        assert_eq!(None, b.next_zero_area(0, usize::MAX, 0));
> +
> +        b.set_area(0, 61); // Now contains {[0, 61)}.
> +        assert_eq!(None, b.next_zero_area(0, 4, 0));
> +        assert_eq!(Some(61), b.next_zero_area(0, 3, 0));
> +        assert_eq!(None, b.next_zero_area(0, 1, 63));
> +        Ok(())
> +    }
> +
> +    #[test]
> +    #[cfg(not(CONFIG_RUST_BITMAP_HARDENED))]
> +    fn bitmap_area_invalid_align() -> Result<(), AllocError> {
> +        let mut b = BitmapVec::new(64, GFP_KERNEL)?;
> +        b.set_bit(0);
> +
> +        assert_eq!(Some(1), b.next_zero_bit(1));
> +        // If this isn't rejected, it would cause a hang in the C code.
> +        assert_eq!(None, b.next_zero_area(1, 1, usize::MAX));
> +        // Reject non `2^k - 1` alignment masks.
> +        assert_eq!(None, b.next_zero_area(1, 1, 2));
> +        assert_eq!(None, b.next_zero_area(1, 1, 5));
> +        Ok(())
> +    }
> +
> +    #[test]
> +    #[cfg(not(CONFIG_RUST_BITMAP_HARDENED))]
> +    fn owned_bitmap_area_out_of_bounds() -> Result<(), AllocError> {
> +        let mut b = BitmapVec::new(64, GFP_KERNEL)?;
> +
> +        // Should be ignored since out of bounds.
> +        b.set_area(64, 4);
> +        b.set_area(62, 8);
> +        b.set_area(usize::MAX, 0);
> +        b.clear_area(usize::MAX, 0);
> +        b.clear_area(2048, 8);
> +        assert_eq!(None, b.next_bit(0));
> +        assert_eq!(None, b.next_zero_area(64, 1, 0));
> +        Ok(())
> +    }
>  }
> 
> -- 
> 2.54.0

Re: [PATCH 2/4] rust: bitmap: add contiguous area operations

[Alice Ryhl]

On Mon, Jul 06, 2026 at 12:29:00PM -0400, Yury Norov wrote:
> On Fri, Jul 03, 2026 at 07:16:05PM +0900, Eliot Courtney wrote:
> > Add bindings and helpers for area operations on bitmaps. Each one is
> > made safe by adding some extra checks compared to the underlying C code
> > (for example, checking bounds) and with additional checks to catch
> > likely erroneous usage if `CONFIG_RUST_BITMAP_HARDENED` is on.
> > 
> > The C code uses signed integers for some parameters, for example the
> > length for `__bitmap_set`, so bounds check against i32::MAX. We can't
> > rely on `BitmapVec::MAX_LEN` because `Bitmap` may not necessarily be
> > backed by `BitmapVec`. There's also a few cases where a non power of two
> > minus one `align_mask` can cause an infinite loop in the C code (can
> > happen on overflow), so check for that.
> > 
> > Add tests demonstrating the edge cases.
> > 
> > Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
> > ---
> >  rust/helpers/bitmap.c |  22 +++++
> >  rust/kernel/bitmap.rs | 219 ++++++++++++++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 241 insertions(+)
> > 
> > diff --git a/rust/helpers/bitmap.c b/rust/helpers/bitmap.c
> > index e4e9f4361270..dac5c03f2448 100644
> > --- a/rust/helpers/bitmap.c
> > +++ b/rust/helpers/bitmap.c
> > @@ -8,3 +8,25 @@ void rust_helper_bitmap_copy_and_extend(unsigned long *to, const unsigned long *
> >  {
> >  	bitmap_copy_and_extend(to, from, count, size);
> >  }
> > +
> > +__rust_helper
> > +unsigned long rust_helper_bitmap_find_next_zero_area(unsigned long *map,
> > +						     unsigned long size,
> > +						     unsigned long start,
> > +						     unsigned int nr,
> > +						     unsigned long align_mask)
> > +{
> > +	return bitmap_find_next_zero_area(map, size, start, nr, align_mask);
> > +}
> > +
> > +__rust_helper
> > +void rust_helper_bitmap_set(unsigned long *map, unsigned int start, unsigned int nbits)
> > +{
> > +	bitmap_set(map, start, nbits);
> > +}
> > +
> > +__rust_helper
> > +void rust_helper_bitmap_clear(unsigned long *map, unsigned int start, unsigned int nbits)
> > +{
> > +	bitmap_clear(map, start, nbits);
> > +}
> 
> All three are the wrappers around the regular outline functions:
> bitmap_find_next_zero_area_off(), __bitmap_set() and __bitmap_clear().
> 
> The inlined version in headers is optimized for small bitmaps. But the
> optimization is all based on inlining in the C code. It doesn't work
> if you wrap it with a rust helper.
> 
> There was a discussion about the similar find_next_bit(). The function
> itself is an inliner, but it's a wrapper around the true outlined
> _find_next_bit(). So we decided to minimize the binder size for that
> type of functions.
> 
> Please, keep the binder minimal unless necessary.

If we can just call __bitmap_clear() without any downsides, then I agree
we should do that, but we actually do support inlining the helpers now.
See CONFIG_RUST_INLINE_HELPERS.

Alice

Re: [PATCH 2/4] rust: bitmap: add contiguous area operations

[Gary Guo]

On Mon Jul 6, 2026 at 6:21 PM BST, Alice Ryhl wrote:
> On Mon, Jul 06, 2026 at 12:29:00PM -0400, Yury Norov wrote:
>> All three are the wrappers around the regular outline functions:
>> bitmap_find_next_zero_area_off(), __bitmap_set() and __bitmap_clear().
>> 
>> The inlined version in headers is optimized for small bitmaps. But the
>> optimization is all based on inlining in the C code. It doesn't work
>> if you wrap it with a rust helper.
>> 
>> There was a discussion about the similar find_next_bit(). The function
>> itself is an inliner, but it's a wrapper around the true outlined
>> _find_next_bit(). So we decided to minimize the binder size for that
>> type of functions.
>> 
>> Please, keep the binder minimal unless necessary.
>
> If we can just call __bitmap_clear() without any downsides, then I agree
> we should do that, but we actually do support inlining the helpers now.
> See CONFIG_RUST_INLINE_HELPERS.

bitmap uses __builtin_constant_p which will only work with pure C inlining and
not LLVM IR based inlining.

Best,
Gary

[PATCH 3/4] rust: id_pool: add contiguous area allocation

[Eliot Courtney]

Add support for contiguous area allocation. Add a new type,
`UnusedArea`, following the same pattern as `UnusedId`.

Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
---
 rust/kernel/id_pool.rs | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

diff --git a/rust/kernel/id_pool.rs b/rust/kernel/id_pool.rs
index 384753fe0e44..b471bfd97487 100644
--- a/rust/kernel/id_pool.rs
+++ b/rust/kernel/id_pool.rs
@@ -4,6 +4,11 @@
 
 //! Rust API for an ID pool backed by a [`BitmapVec`].
 
+use core::{
+    num::NonZero,
+    ops::Range, //
+};
+
 use crate::alloc::{AllocError, Flags};
 use crate::bitmap::BitmapVec;
 
@@ -240,6 +245,33 @@ pub fn find_unused_id(&mut self, offset: usize) -> Option<UnusedId<'_>> {
     pub fn release_id(&mut self, id: usize) {
         self.map.clear_bit(id);
     }
+
+    /// Finds a contiguous area of `count` unused IDs at or after `offset`.
+    ///
+    /// `align_mask` must be `0` (no alignment) or one less than a power of two, in which case the
+    /// start of the returned area is a multiple of that power of two.
+    ///
+    /// Returns an [`UnusedArea`] upon success, or [`None`] if no such area could be found.
+    #[inline]
+    #[must_use]
+    pub fn find_unused_area(
+        &mut self,
+        offset: usize,
+        count: NonZero<usize>,
+        align_mask: usize,
+    ) -> Option<UnusedArea<'_>> {
+        let start = self.map.next_zero_area(offset, count.get(), align_mask)?;
+        Some(UnusedArea {
+            range: start..start + count.get(),
+            pool: self,
+        })
+    }
+
+    /// Releases a contiguous area of IDs.
+    #[inline]
+    pub fn release_area(&mut self, range: &Range<usize>) {
+        self.map.clear_area(range.start, range.len());
+    }
 }
 
 /// Represents an unused id in an [`IdPool`].
@@ -287,6 +319,42 @@ pub fn acquire(self) -> usize {
     }
 }
 
+/// Represents an unused, contiguous area of IDs in an [`IdPool`].
+///
+/// # Invariants
+///
+/// `range.start <= range.end <= pool.map.len()`.
+#[must_use = "the ID range is not reserved unless acquired"]
+pub struct UnusedArea<'pool> {
+    range: Range<usize>,
+    pool: &'pool mut IdPool,
+}
+
+impl<'pool> UnusedArea<'pool> {
+    /// Returns the unused ID range.
+    ///
+    /// Be aware that the area has not yet been acquired in the pool. The
+    /// [`acquire`] method must be called to prevent others from taking it.
+    ///
+    /// [`acquire`]: UnusedArea::acquire()
+    #[inline]
+    #[must_use]
+    pub fn range(&self) -> Range<usize> {
+        self.range.clone()
+    }
+
+    /// Acquires the area.
+    ///
+    /// Returns the now-reserved ID range.
+    #[inline]
+    pub fn acquire(self) -> Range<usize> {
+        let Self { range, pool } = self;
+        // By the type invariants, the range is within bounds.
+        pool.map.set_area(range.start, range.end - range.start);
+        range
+    }
+}
+
 impl Default for IdPool {
     #[inline]
     fn default() -> Self {

-- 
2.54.0

Re: [PATCH 3/4] rust: id_pool: add contiguous area allocation

[Greg KH]

On Fri, Jul 03, 2026 at 07:16:06PM +0900, Eliot Courtney wrote:
> Add support for contiguous area allocation. Add a new type,
> `UnusedArea`, following the same pattern as `UnusedId`.
> 
> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>

Why isn't the built-in idr library being used here instead of rolling
your own data structure?

thanks,

greg k-h

[PATCH 4/4] gpu: nova-core: add ChannelIdPool

[Eliot Courtney]

Add `ChannelIdPool` which adds automatic tracking and releasing of
channel IDs on top of `IdPool`. This is necessary for apportioning
ranges of channel IDs to be used in e.g. vGPU.

Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
---
 drivers/gpu/nova-core/gpu.rs         |   2 +
 drivers/gpu/nova-core/gpu/channel.rs | 134 +++++++++++++++++++++++++++++++++++
 2 files changed, 136 insertions(+)

diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
index 43c3f4f8df71..0c3b5de7d849 100644
--- a/drivers/gpu/nova-core/gpu.rs
+++ b/drivers/gpu/nova-core/gpu.rs
@@ -31,6 +31,8 @@
     regs,
 };
 
+#[cfg_attr(not(CONFIG_KUNIT = "y"), expect(dead_code))]
+mod channel;
 mod hal;
 
 macro_rules! define_chipset {
diff --git a/drivers/gpu/nova-core/gpu/channel.rs b/drivers/gpu/nova-core/gpu/channel.rs
new file mode 100644
index 000000000000..5d745e4dc080
--- /dev/null
+++ b/drivers/gpu/nova-core/gpu/channel.rs
@@ -0,0 +1,134 @@
+// SPDX-License-Identifier: GPL-2.0
+// SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+
+//! Channel ID allocation.
+
+use core::{
+    num::NonZero,
+    ops::{
+        Deref,
+        Range, //
+    }, //
+};
+
+use kernel::{
+    id_pool::IdPool,
+    prelude::*,
+    sync::{
+        new_mutex,
+        Mutex, //
+    }, //
+};
+
+/// Pool for tracking reservations of channel IDs.
+#[pin_data]
+pub(crate) struct ChannelIdPool {
+    #[pin]
+    inner: Mutex<IdPool>,
+    num_chids: usize,
+}
+
+impl ChannelIdPool {
+    /// Creates a pool managing `num_chids` channel IDs.
+    pub(crate) fn new(num_chids: usize) -> impl PinInit<Self, Error> {
+        try_pin_init!(Self {
+            inner <- new_mutex!(IdPool::with_capacity(num_chids, GFP_KERNEL)?),
+            num_chids,
+        })
+    }
+
+    /// Reserves a contiguous area of `count` channel IDs, returning a guard
+    /// that releases the area on drop.
+    pub(crate) fn alloc_area(&self, count: NonZero<usize>) -> Result<ChannelIdArea<'_>> {
+        let mut ids = self.inner.lock();
+        let area = ids.find_unused_area(0, count, 0).ok_or(ENOSPC)?;
+
+        // If the pool is small, the backing bitmap may be rounded up to a larger size.
+        if area.range().end > self.num_chids {
+            return Err(ENOSPC);
+        }
+        Ok(ChannelIdArea {
+            pool: self,
+            range: area.acquire(),
+        })
+    }
+}
+
+/// A reserved contiguous area of channel IDs.
+///
+/// Releases the whole area back to its [`ChannelIdPool`] when dropped. Releasing locks a
+/// sleeping [`Mutex`], so the area must be dropped in a context that is allowed to sleep.
+#[must_use = "the channel ID area is released immediately when unused"]
+pub(crate) struct ChannelIdArea<'a> {
+    pool: &'a ChannelIdPool,
+    range: Range<usize>,
+}
+
+impl Drop for ChannelIdArea<'_> {
+    fn drop(&mut self) {
+        self.pool.inner.lock().release_area(&self.range);
+    }
+}
+
+impl Deref for ChannelIdArea<'_> {
+    type Target = Range<usize>;
+
+    fn deref(&self) -> &Self::Target {
+        &self.range
+    }
+}
+
+#[kunit_tests(nova_core_channel)]
+mod tests {
+    use super::*;
+
+    #[test]
+    fn chid_area() -> Result {
+        let pool = KBox::pin_init(ChannelIdPool::new(2048), GFP_KERNEL)?;
+        let area_size = NonZero::new(48).ok_or(EINVAL)?;
+
+        let first = pool.alloc_area(area_size)?;
+        assert_eq!(0, first.start);
+        assert_eq!(area_size.get(), first.len());
+        assert_eq!(area_size.get(), first.end);
+
+        let second = pool.alloc_area(area_size)?;
+        assert!(first.end <= second.start || second.end <= first.start);
+
+        let first_start = first.start;
+        drop(first);
+        assert_eq!(first_start, pool.alloc_area(area_size)?.start);
+        Ok(())
+    }
+
+    #[test]
+    fn chid_bounded_by_num_chids() -> Result {
+        let pool = KBox::pin_init(ChannelIdPool::new(4), GFP_KERNEL)?;
+        let one = NonZero::new(1).ok_or(EINVAL)?;
+        let two = NonZero::new(2).ok_or(EINVAL)?;
+        let three = NonZero::new(3).ok_or(EINVAL)?;
+        let four = NonZero::new(4).ok_or(EINVAL)?;
+        let five = NonZero::new(5).ok_or(EINVAL)?;
+
+        {
+            let a = pool.alloc_area(one)?;
+            let b = pool.alloc_area(one)?;
+            let c = pool.alloc_area(one)?;
+            let d = pool.alloc_area(one)?;
+            assert_eq!(0, a.start);
+            assert_eq!(1, b.start);
+            assert_eq!(2, c.start);
+            assert_eq!(3, d.start);
+            assert_eq!(Err(ENOSPC), pool.alloc_area(one).map(|_| ()));
+        }
+
+        assert_eq!(0, pool.alloc_area(four)?.start);
+        assert_eq!(Err(ENOSPC), pool.alloc_area(five).map(|_| ()));
+
+        let head = pool.alloc_area(three)?;
+        assert_eq!(0, head.start);
+        assert_eq!(Err(ENOSPC), pool.alloc_area(two).map(|_| ()));
+        assert_eq!(3, pool.alloc_area(one)?.start);
+        Ok(())
+    }
+}

-- 
2.54.0

Re: [PATCH 0/4] rust: Add support for reserving of ranges of IDs

[Alice Ryhl]

On Fri, Jul 03, 2026 at 07:16:03PM +0900, Eliot Courtney wrote:
> Add support for reserving of ranges of IDs, with a usage in nova-core
> for channel IDs. This entails adding the helpers+users of the C bitmap
> API for ranges of bits, then users of that in `IdPool`, and finally a
> user of `IdPool` in nova-core, `ChannelIdPool`.

If you need ranges of IDs, perhaps you want the maple tree instead?

Alice

Re: [PATCH 0/4] rust: Add support for reserving of ranges of IDs

[Gary Guo]

On Mon Jul 6, 2026 at 12:48 PM BST, Alice Ryhl wrote:
> On Fri, Jul 03, 2026 at 07:16:03PM +0900, Eliot Courtney wrote:
>> Add support for reserving of ranges of IDs, with a usage in nova-core
>> for channel IDs. This entails adding the helpers+users of the C bitmap
>> API for ranges of bits, then users of that in `IdPool`, and finally a
>> user of `IdPool` in nova-core, `ChannelIdPool`.
>
> If you need ranges of IDs, perhaps you want the maple tree instead?
>
> Alice

Any reason that the current ID pool is implemented directly on top of bitmap
rather than using IDA?

Best,
Gary

Re: [PATCH 0/4] rust: Add support for reserving of ranges of IDs

[Alice Ryhl]

On Mon, Jul 06, 2026 at 12:53:24PM +0100, Gary Guo wrote:
> On Mon Jul 6, 2026 at 12:48 PM BST, Alice Ryhl wrote:
> > On Fri, Jul 03, 2026 at 07:16:03PM +0900, Eliot Courtney wrote:
> >> Add support for reserving of ranges of IDs, with a usage in nova-core
> >> for channel IDs. This entails adding the helpers+users of the C bitmap
> >> API for ranges of bits, then users of that in `IdPool`, and finally a
> >> user of `IdPool` in nova-core, `ChannelIdPool`.
> >
> > If you need ranges of IDs, perhaps you want the maple tree instead?
> >
> > Alice
> 
> Any reason that the current ID pool is implemented directly on top of bitmap
> rather than using IDA?

To some extent it's because that's how C Binder did it. Though I do also
think that the bitmap fits binder's needs pretty well. Almost no Binder
processes will have more than 8 handles in use, in which case the
BitmapVec is extremely efficient because no allocation or pointer
indirection is used. And the bitmap also performs well for the few
processes with many external handles.

But it could also use the xarray instead. Nothing stopping that.

Alice