Re: [PATCH v11 4/5] rust: id_pool: do not round capacity up to BitmapVec::MAX_INLINE_LEN

[Yury Norov]

On Wed, Nov 11, 2026 at 07:44:19AM +0900, Alexandre Courbot wrote:
> On Wed Nov 11, 2026 at 2:42 AM JST, Yury Norov wrote:
> > On Mon, Nov 09, 2026 at 05:32:52PM +0900, Eliot Courtney wrote:
> >> Current code in IdPool::with_capacity rounds the capacity up to
> >> BitmapVec::MAX_INLINE_LEN, but BitmapVec::new works fine with values
> >> smaller than this and still uses an inline representation. Remove this
> >> behaviour.
> >> 
> >> This allows specifying a real capacity of 0, which was not previously
> >> possible.
> >
> > How real capacity 0 became possible? Did we eventually find a use case
> > for it? If not, it should not be possible, and the implementation
> > should not explicitly handle that case.
> >
> >> This breaks `grow_request` in this case, so change it to grow
> >> to at least `BitmapVec::MAX_INLINE_LEN`, mirroring the capacity floor in
> >> `shrink_request`.
> >
> > Not the grow_request only, I believe. I recall the discussion about
> > panic on most operations on a 0-bit pool.
> 
> You have panics on most operations of a pool of any size if accessed out
> of bounds. Zero size is not special.
> 
> >  
> >> Reviewed-by: Alice Ryhl <aliceryhl@xxxxxxxxxx>
> >> Reviewed-by: Burak Emir <burak.emir@xxxxxxxxx>
> >> Signed-off-by: Eliot Courtney <ecourtney@xxxxxxxxxx>
> >> ---
> >>  rust/kernel/id_pool.rs | 38 ++++++++++++++++++++++++++++++++------
> >>  1 file changed, 32 insertions(+), 6 deletions(-)
> >> 
> >> diff --git a/rust/kernel/id_pool.rs b/rust/kernel/id_pool.rs
> >> index 92eeb7caa243..f77bd90325ff 100644
> >> --- a/rust/kernel/id_pool.rs
> >> +++ b/rust/kernel/id_pool.rs
> >> @@ -112,13 +112,8 @@ pub fn new() -> Self {
> >>      }
> >>  
> >>      /// Constructs a new [`IdPool`] with space for a specific number of bits.
> >> -    ///
> >> -    /// A capacity below [`MAX_INLINE_LEN`] is adjusted to [`MAX_INLINE_LEN`].
> >> -    ///
> >> -    /// [`MAX_INLINE_LEN`]: BitmapVec::MAX_INLINE_LEN
> >>      #[inline]
> >>      pub fn with_capacity(num_ids: usize, flags: Flags) -> Result<Self, AllocError> {
> >> -        let num_ids = usize::max(num_ids, BitmapVec::MAX_INLINE_LEN);
> >>          let map = BitmapVec::new(num_ids, flags)?;
> >>          Ok(Self { map })
> >>      }
> >> @@ -152,6 +147,13 @@ pub fn capacity(&self) -> usize {
> >>      /// let resizer = alloc_request.realloc(GFP_KERNEL)?;
> >>      /// pool.shrink(resizer);
> >>      /// assert_eq!(pool.capacity(), BitmapVec::MAX_INLINE_LEN);
> >> +    ///
> >> +    /// // A pool at the `MAX_INLINE_LEN` floor cannot shrink further.
> >> +    /// assert!(pool.shrink_request().is_none());
> >> +    ///
> >> +    /// // Neither can a pool with a capacity below `MAX_INLINE_LEN`.
> >> +    /// let small = IdPool::with_capacity(8, GFP_KERNEL)?;
> >> +    /// assert!(small.shrink_request().is_none());
> >>      /// # Ok::<(), AllocError>(())
> >>      /// ```
> >>      #[inline]
> >> @@ -198,12 +200,36 @@ pub fn shrink(&mut self, mut resizer: PoolResizer) {
> >>  
> >>      /// Returns a [`ReallocRequest`] for growing this [`IdPool`], if possible.
> >>      ///
> >> +    /// Grows to at least [`MAX_INLINE_LEN`].
> >>      /// The capacity of an [`IdPool`] cannot be grown above [`MAX_LEN`].
> >>      ///
> >> +    /// [`MAX_INLINE_LEN`]: BitmapVec::MAX_INLINE_LEN
> >>      /// [`MAX_LEN`]: BitmapVec::MAX_LEN
> >> +    ///
> >> +    /// # Examples
> >> +    ///
> >> +    /// ```
> >> +    /// use kernel::{
> >> +    ///     alloc::AllocError,
> >> +    ///     bitmap::BitmapVec,
> >> +    ///     id_pool::IdPool, //
> >> +    /// };
> >> +    ///
> >> +    /// // Grow goes to at least BitmapVec::MAX_INLINE_LEN.
> >> +    /// let mut pool = IdPool::with_capacity(1, GFP_KERNEL)?;
> >> +    /// let resizer = pool.grow_request().ok_or(AllocError)?.realloc(GFP_KERNEL)?;
> >> +    /// pool.grow(resizer);
> >> +    /// assert_eq!(pool.capacity(), BitmapVec::MAX_INLINE_LEN);
> >> +    ///
> >> +    /// // Grow doubles if at least BitmapVec::MAX_INLINE_LEN.
> >> +    /// let resizer = pool.grow_request().ok_or(AllocError)?.realloc(GFP_KERNEL)?;
> >> +    /// pool.grow(resizer);
> >> +    /// assert_eq!(pool.capacity(), 2 * BitmapVec::MAX_INLINE_LEN);
> >> +    /// # Ok::<(), AllocError>(())
> >> +    /// ```
> >>      #[inline]
> >>      pub fn grow_request(&self) -> Option<ReallocRequest> {
> >> -        let num_ids = self.capacity() * 2;
> >> +        let num_ids = usize::max(BitmapVec::MAX_INLINE_LEN, self.capacity() * 2);
> >
> > You only need this max(...) thing to fix the behavior of 0-len bitmap.
> > We don't have any users with the request to support them. Please don't
> > add any extra code to handle unwanted and unsupported cases.
> 
> No, this code is a side-effect of the pool not being rounded up to
> `MAX_INLINE_LEN` (note how the `max` moved from `with_capacity). It
> would still be there even if we did not support zero-size.

The commit message says exactly opposite:

  This allows specifying a real capacity of 0, which was not previously
  possible.

Eliot, can you reword please? We don't have a single use-case for
0-sized bitmap, nor in C, neither in rust. If your code handles such
a bitmap correctly to some extend, it's purely accidentally, and
nobody should rely on it.
 
> Forbidding zero-sized pools would actually require *more* code in this
> patch to enforce that rule, and would not allow us to remove any in
> exchange afaict.

I trust you here. Maybe declaring nbits in the allocation API as
NonZero would help - IDK... I just want to make sure we're not
bloating the implementation for unneeded and confusing functionality.

Thanks,
Yury