dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Eliot Courtney" <ecourtney@nvidia.com>
Cc: dri-devel@lists.freedesktop.org, ojeda@kernel.org,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	gary@garyguo.net
Subject: Re: [PATCH v9 7/9] rust: id_pool: add contiguous ID reservation
Date: Wed, 30 Sep 2026 02:51:37 +0000	[thread overview]
Message-ID: <20260930025138.0895F1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260930-chid-v9-7-0d6cca376cff@nvidia.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] rust: id_pool: reserve_ids() and find_unused_id() panic when offset >= capacity
--

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

rust: id_pool: add contiguous ID reservation

Add `IdPool::reserve_ids` which allocates a contiguous range with the
given offset, count, and alignment.

> diff --git a/rust/kernel/id_pool.rs b/rust/kernel/id_pool.rs
> index 384753fe0e44a..06a4c71c4c6c9 100644
> --- a/rust/kernel/id_pool.rs
> +++ b/rust/kernel/id_pool.rs

[ ... ]

> @@ -240,6 +246,32 @@ pub fn find_unused_id(&mut self, offset: usize) -> Option<UnusedId<'_>> {
>      pub fn release_id(&mut self, id: usize) {
>          self.map.clear_bit(id);
>      }
> +
> +    /// Reserves a contiguous area of `count` IDs at or after `offset`.
> +    ///
> +    /// The start of the returned area is a multiple of `align`.
> +    ///
> +    /// Returns the reserved range upon success, or [`None`] if no such area could be found.
> +    #[inline]
> +    #[must_use]
> +    pub fn reserve_ids(
> +        &mut self,
> +        offset: usize,
> +        count: NonZero<usize>,
> +        align: Alignment,
> +    ) -> Option<Range<usize>> {
> +        let start = self.map.next_zero_area(offset, count, align)?;

[Severity: High]
Does this code panic when offset is greater than or equal to pool.capacity()?

If a caller attempts to reserve an ID in an IdPool where the requested
offset is greater than or equal to pool.capacity(), IdPool::reserve_ids()
passes offset directly to BitmapVec::next_zero_area() without bounds validation.

This can trivially occur if a caller instantiates an empty pool
(IdPool::with_capacity(0)) or resumes searching for an ID by passing
offset = last_id + 1 when last_id was the last available ID.

The underlying BitmapVec::next_zero_area() function calls
next_zero_area_off() in rust/kernel/bitmap.rs, which contains a
bitmap_assert!(start < self.len()) that expands to a hard assert! under
CONFIG_RUST_BITMAP_HARDENED, leading to a kernel panic (denial of service).

Since IdPool is documented to return None to prompt a grow_request
when no IDs are available, failing to handle offset >= self.capacity()
gracefully breaks the resizing API and causes panics on legitimate resource
pool usage patterns.

It appears IdPool::find_unused_id() also shares this behavior when calling
self.map.next_zero_bit(offset)? without bounds checking.

> +        self.map.set(start, count);
> +        Some(start..start + count.get())
> +    }
> +
> +    /// Releases a contiguous area of IDs.
> +    #[inline]
> +    pub fn release_ids(&mut self, range: &Range<usize>) {
> +        if let Some(nbits) = NonZero::new(range.len()) {
> +            self.map.clear(range.start, nbits);
> +        }
> +    }
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260930-chid-v9-0-0d6cca376cff@nvidia.com?part=7

  reply	other threads:[~2026-09-30  2:51 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-30  2:42 [PATCH v9 0/9] rust: Add support for reserving of ranges of IDs Eliot Courtney
2026-09-30  2:42 ` [PATCH v9 1/9] rust: bitmap: use function-level cfg on kunit test Eliot Courtney
2026-09-30  2:42 ` [PATCH v9 2/9] rust: bitmap: restrict bitmap length to at most i32::MAX Eliot Courtney
2026-09-30  2:42 ` [PATCH v9 3/9] rust: sizes: add sub-1K size constants Eliot Courtney
2026-09-30  9:12   ` Miguel Ojeda
2026-09-30 11:04     ` Alexandre Courbot
2026-09-30 11:22       ` Miguel Ojeda
2026-10-01  0:40         ` Gary Guo
2026-10-01  5:23           ` Eliot Courtney
2026-09-30  2:42 ` [PATCH v9 4/9] rust: sizes: implement SizeConstants for Alignment Eliot Courtney
2026-09-30  9:12   ` Miguel Ojeda
2026-09-30  2:42 ` [PATCH v9 5/9] rust: use Alignment size constants Eliot Courtney
2026-09-30  2:42 ` [PATCH v9 6/9] rust: bitmap: add contiguous area operations Eliot Courtney
2026-09-30  4:41   ` Yury Norov
2026-09-30  2:42 ` [PATCH v9 7/9] rust: id_pool: add contiguous ID reservation Eliot Courtney
2026-09-30  2:51   ` sashiko-bot [this message]
2026-09-30  4:50   ` Yury Norov
2026-09-30  2:42 ` [PATCH v9 8/9] rust: id_pool: do not round capacity up to BitmapVec::MAX_INLINE_LEN Eliot Courtney
2026-09-30  2:52   ` sashiko-bot
2026-09-30  5:05   ` Yury Norov
2026-10-01  6:20     ` Alexandre Courbot
2026-10-08 15:47       ` Yury Norov
2026-10-08 16:04         ` Gary Guo
2026-10-09 14:07         ` Alexandre Courbot
2026-09-30  2:42 ` [PATCH v9 9/9] gpu: nova-core: add ChannelIdPool Eliot Courtney
2026-10-08 15:04 ` [PATCH v9 0/9] rust: Add support for reserving of ranges of IDs Alexandre Courbot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260930025138.0895F1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ecourtney@nvidia.com \
    --cc=gary@garyguo.net \
    --cc=ojeda@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox