Re: [PATCH v9 8/9] rust: id_pool: do not round capacity up to BitmapVec::MAX_INLINE_LEN

["Alexandre Courbot" <acourbot@nvidia.com>]

On Fri Oct 9, 2026 at 12:47 AM JST, Yury Norov wrote:
> On Thu, Oct 01, 2026 at 03:20:40PM +0900, Alexandre Courbot wrote:
>> On Wed Sep 30, 2026 at 2:05 PM JST, Yury Norov wrote:
>
> ...
>
>> > Allocating a pool with 0-bit capacity is wrong. Please don't put it
>> > in the examples. I recall I pointed that this object would panic the
>> > kernel if, for example, you call pool.next_zero_bit(0) immediately
>> > after this. Sorry, but NAK.
>> >
>> > This .with_capacity() should take num_ids: NonZero, after all...
>> 
>> This panic is not specific to the size zero, any size triggers the same
>> behavior when accessed out of bounds.
>
> In C, malloc(0) is implementation defined behavior, i.e. it can return
> a pointer valid for free(), or NULL (which is also valid for free).
>
> This is a very old legacy coming from K&R implementation, then rejected
> in C89, and later this all became an impl-def, mostly for compatibility
> reasons. See 7.20.3 in
>
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n937.pdf
>
> Rust adopted C bitmaps, thus creating 0-bit bitmap may go through, and
> hit that questionable behavior. You add this example without any
> discussion about all that possible complications, and with no
> protection for users.
>
> Interestingly, you're doing it for the reason that has been considered
> a bad practice for over 30 years ago - malloc(0) with the immediate
> realloc(). See the above link for details.
>
> To me it looks like pulling legacy with a potential of undefined behavior
> into Rust.
>
> Bitmaps is a way more simple case than the generic malloc(). There's the
> only user of bitmaps - the Linux kernel, so we know exactly all users and
> their user patterns. I'm not aware of any in-tree user allocating 0-length
> bitmap for whatever reason, and such a coding style is highly unwelcome
> nowadays (30+ years).
>
> When it comes to rust, things are even simpler. Rust has much stricter
> memory policy - no undefined behavior, no implementation-defined behavior
> is allowed, no 50-years old legacy has to be considered.
>
> Rust community decided to take the existing in-kernel implementation of
> bitmaps written in C, for a reason. But with that it pulls all undefined
> and poorly defined behavior associate to C language. We did quite well
> spotting such places and fencing them with safety checks.
>
> The 0-length bitmaps is just another case that should be resolved.

As it turns out we would never perform a zero-sized malloc, even for a
zero-sized bitmap. `IdPool` is backed by a `BitmapVec`, which up to
`usize::BITS` uses an inline member as backing storage. So we would
never call `bitmap_zalloc` with a value of 0, making the safety concern
moot.

>
> If you still think that you need 0-length bitmaps in Rust, can you please
> give the clear and thorough explanation why rust needs those 0-length
> bitmaps. Are there any in-kernel examples? Any language concepts requiring
> it? If not, it's still a NAK.

I don't know of an in-kernel example, but please look at the
`bitmap_vec_new` test which has been here since the API was initially
merged last year: the first thing it does is create a zero-sized bitmap.

It is also easy to imagine a user starting with an empty pool and
growing it on-demand. Having the ability to create a zero-sized pool is
convenient to avoid special-casing user code, and in this case I'd say
expected, just like you can create a zero-sized vector. Again a size of
zero does not trigger anything that a larger capacity cannot trigger, so
I don't see a reason to forbid it.

>
>> A size of zero has nothing special
>> in that respect, so why make an exception and forbid it? We had this
>> discussion some time ago [1][2], and I'd recommend instead making e.g.
>> `next_zero_bit` return `None` on out-of-bounds accesses, which is
>> semantically correct.
>
> No. out-of-bound access should panic because every caller of bitmap
> API knows the length of that bitmap.

Right now out-of-bound accesses are allowed if
`CONFIG_RUST_BITMAP_HARDENED` is not set. The Kconfig documentation for
that option even says "if unsure, say N", which suggests that not
panicking (and thus the behavior I described above for `next_zero_bit`)
is the default. If out-of-bound accesses should panic, then the Kconfig
does not reflect that.

>
> But if you make that 0-length bitmap a valid case, we need to revisit
> every function and make sure it returns ENOENT or something instead of
> panicking. That, again, must be very well explained and justified, and
> all this has to be done before adding 0-length bitmap support in code
> and examples.

With hardening off, every function already behaves in that way, and
existing user code is already written to not trigger that condition
anyway (because of the possibility of a panic), so that would be a
pretty innocuous change.