[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

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

[Alice Ryhl]

On Fri, Jul 3, 2026 at 12:19 PM Eliot Courtney <ecourtney@nvidia.com> wrote:
>
> Since commit c652dc44192d ("rust: kunit: allow `cfg` on `test`s"),
> we no longer need this workaround.
>
> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>

Reviewed-by: Alice Ryhl <aliceryhl@google.com>

[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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Integer truncation in `Bitmap::copy_and_extend` leading to out-of-bounds memset in C.
--

commit 19918f0914fec684f788000700e6deb8bdb878e0
Author: Eliot Courtney <ecourtney@nvidia.com>

rust: bitmap: add contiguous area operations

This patch adds bindings and helpers for area operations on bitmaps. It makes
each operation safe by adding extra bounds checks compared to the underlying C
code. Additional checks are included to catch likely erroneous usage when
CONFIG_RUST_BITMAP_HARDENED is enabled.

> diff --git a/rust/kernel/bitmap.rs b/rust/kernel/bitmap.rs
> index a43bfe0ec3dc2..f7290fa439d6f 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)
>          }
>      }
[ ... ]
> +    #[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),

[Severity: High]
This isn't a bug introduced by this patch, but given your note about bounds
checking and 32-bit limits, I noticed a pre-existing issue in
Bitmap::copy_and_extend() that might need similar treatment.

rust/kernel/bitmap.rs:Bitmap::copy_and_extend() {
    ...
    pub fn copy_and_extend(&mut self, src: &Bitmap) {
        let len = core::cmp::min(src.len(), self.len());
        // SAFETY: access to self and src is within bounds.
        unsafe {
            bindings::bitmap_copy_and_extend(
                self.as_mut_ptr(),
                src.as_ptr(),
                len as u32,
                self.len() as u32,
            )
        };
    }
}

Can this lead to an out-of-bounds memset in C?

A Bitmap can be created from a raw pointer using Bitmap::from_raw() without
u32::MAX length restrictions. If self.len() exceeds u32::MAX on 64-bit
systems, the self.len() as u32 cast will silently truncate the length.

If src.len() is smaller than the full length but larger than the truncated
length, count will be greater than size when passed to the C function
bitmap_copy_and_extend().

The C function calculates the byte delta for memset as:
bitmap_size(size) - copy * sizeof(long)

With a truncated size, this would subtract a larger byte count from a smaller
byte count, underflowing to a huge size_t value. Could this cause a massive
out-of-bounds write and kernel panic?

> +            "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) };
> +    }
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-chid-v1-0-84fe8259e46e@nvidia.com?part=2

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The construction of `UnusedArea` is missing the required `// INVARIANT:` comment.
--

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

rust: id_pool: add contiguous area allocation

This commit adds support for contiguous area allocation to the ID pool by
introducing a new UnusedArea type that follows the same pattern as UnusedId.

> diff --git a/rust/kernel/id_pool.rs b/rust/kernel/id_pool.rs
> index 384753fe0e44a..b471bfd974875 100644
> --- a/rust/kernel/id_pool.rs
> +++ b/rust/kernel/id_pool.rs
[ ... ]
> @@ -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,
> +        })

[Severity: Low]
This isn't a bug, but should this UnusedArea instantiation include an
// INVARIANT: comment?

The Rust subsystem guidelines state that when a struct with an # Invariants
documentation section is constructed, the code should have an // INVARIANT:
comment explaining why the invariants are satisfied.

UnusedArea defines the invariant range.start <= range.end <= pool.map.len().
Would it be appropriate to add a comment here detailing why the bounds
guaranteed by next_zero_area() satisfy this invariant?

> +    }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-chid-v1-0-84fe8259e46e@nvidia.com?part=3

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

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

[Eliot Courtney]

On Fri Jul 3, 2026 at 7:31 PM JST, Greg KH wrote:
> 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

For nova-core in this series, we need allocation of a contiguous
sequence of IDs with a specific length and sometimes a specific
alignment. IIUC, IDA/xarray do not support that (I checked
ida_alloc_range and it only allocates a single ID in a range, not a
contiguous sequence).

For IdPool before this series, I think it could have used IDA/xarray.
See [1] where Alice has posted some more context.

w.r.t. the structure choice, the IDs we need to allocate are channel
IDs, and the total range is limited to 2048 of them, so IMO bitmaps are
a better fit than e.g. maple tree.

Thanks!

[1] https://lore.kernel.org/all/akujuAJOZxRJlQZo@google.com/

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

[Greg KH]

On Tue, Jul 07, 2026 at 10:25:27PM +0900, Eliot Courtney wrote:
> On Fri Jul 3, 2026 at 7:31 PM JST, Greg KH wrote:
> > 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
> 
> For nova-core in this series, we need allocation of a contiguous
> sequence of IDs with a specific length and sometimes a specific
> alignment. IIUC, IDA/xarray do not support that (I checked
> ida_alloc_range and it only allocates a single ID in a range, not a
> contiguous sequence).
> 
> For IdPool before this series, I think it could have used IDA/xarray.
> See [1] where Alice has posted some more context.
> 
> w.r.t. the structure choice, the IDs we need to allocate are channel
> IDs, and the total range is limited to 2048 of them, so IMO bitmaps are
> a better fit than e.g. maple tree.

But again, you are having to "roll your own" logic here, please reuse
the data structures we already have in the kernel for this type of
thing.  If a maple tree works, please use it.

thanks,

greg k-h

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

[Yury Norov]

On Tue, Jul 07, 2026 at 04:13:30PM +0200, Greg KH wrote:
> On Tue, Jul 07, 2026 at 10:25:27PM +0900, Eliot Courtney wrote:
> > On Fri Jul 3, 2026 at 7:31 PM JST, Greg KH wrote:
> > > 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
> > 
> > For nova-core in this series, we need allocation of a contiguous
> > sequence of IDs with a specific length and sometimes a specific
> > alignment. IIUC, IDA/xarray do not support that (I checked
> > ida_alloc_range and it only allocates a single ID in a range, not a
> > contiguous sequence).
> > 
> > For IdPool before this series, I think it could have used IDA/xarray.
> > See [1] where Alice has posted some more context.
> > 
> > w.r.t. the structure choice, the IDs we need to allocate are channel
> > IDs, and the total range is limited to 2048 of them, so IMO bitmaps are
> > a better fit than e.g. maple tree.
> 
> But again, you are having to "roll your own" logic here, please reuse
> the data structures we already have in the kernel for this type of
> thing.  If a maple tree works, please use it.

I asked exactly the same question when Alice and Burak added wrappers
for bitmaps to implement their ID pool. This is the answer:

  An alternative route of vendoring an existing Rust bitmap package was
  considered but suboptimal overall. Reusing the C implementation is
  preferable for a basic data structure like bitmaps. It enables Rust
  code to be a lot more similar and predictable with respect to C code
  that uses the same data structures and enables the use of code that
  has been tried-and-tested in the kernel, with the same performance
  characteristics whenever possible.

And now it's in a commit message: 11eca92a2caeb

They measured the affect of their wrapper on performance, and it appears
to be ~5%. See lib/find_bit_benchmark_rust.rs.

I didn't see any side-to-side comparison between any native Rust API vs
imported C bitmaps. I'm sure, I asked for that, and I still believe
it's the important piece of data to avoid this back-and-forth type of
discussions. So, Alice, Burak or anybody...

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

Now having more context, the ID pool's primary goal is to allocate
individual IDs, which naturally lays on find_bit() API in C. The
native Rust alternative is considered and found 'suboptimal overall'.

This series extends the existing data structure in Rust for Linux, not
adding a new one. So, the series itself looks justified to me because
it's a logical extension of the existing functionality.

Regarding C bindings vs native API... Yes we lack thorough performance
analysis. Do we have such analysis for every data structure in kernel?

No. So to me it's as simple as: they are developers, they know better.

Thanks,
Yury

[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

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

[Eliot Courtney]

On Mon Jul 6, 2026 at 8:48 PM JST, 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

I think maple tree would work, but it looked like not as good a fit to
me because:
- the number of channel IDs is small (limited to 2048)
- allocation of a contiguous sequence of channel IDs is sometimes
  aligned to its size (which should be a power of two, AFAICT) - I
  realise patch 4 doesn't reflect this (yet). The bitmap APIs natively
  support this. 
- maple tree's alloc_range stores a value: T for the range which isn't
  necessary for ID alloc

WDYT?

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

[Alice Ryhl]

On Tue, Jul 7, 2026 at 3:26 PM Eliot Courtney <ecourtney@nvidia.com> wrote:
>
> On Mon Jul 6, 2026 at 8:48 PM JST, 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
>
> I think maple tree would work, but it looked like not as good a fit to
> me because:
> - the number of channel IDs is small (limited to 2048)
> - allocation of a contiguous sequence of channel IDs is sometimes
>   aligned to its size (which should be a power of two, AFAICT) - I
>   realise patch 4 doesn't reflect this (yet). The bitmap APIs natively
>   support this.
> - maple tree's alloc_range stores a value: T for the range which isn't
>   necessary for ID alloc

The limited number of channel IDs (2048) is a good reason to use a
bitmap. Please include this context in the commit message for the next
version.

Alice