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

[Alexandre Courbot]

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.

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.