Rust for Linux List
 help / color / mirror / Atom feed
From: Yury Norov <ynorov@nvidia.com>
To: Eliot Courtney <ecourtney@nvidia.com>
Cc: "Alice Ryhl" <aliceryhl@google.com>,
	"Burak Emir" <burak.emir@gmail.com>,
	"Yury Norov" <yury.norov@gmail.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>, "Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Andreas Hindborg" <a.hindborg@kernel.org>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Tamir Duberstein" <tamird@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Onur Özkan" <work@onurozkan.dev>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Alistair Popple" <apopple@nvidia.com>,
	"Timur Tabi" <ttabi@nvidia.com>, "Zhi Wang" <zhiw@nvidia.com>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	nova-gpu@lists.linux.dev, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v5 4/5] rust: id_pool: add contiguous area allocation
Date: Wed, 12 Aug 2026 17:16:36 -0400	[thread overview]
Message-ID: <anzitCSFv28wKWeX@yury> (raw)
In-Reply-To: <20260812-chid-v5-4-6c767770b3f4@nvidia.com>

On Wed, Aug 12, 2026 at 05:51:24PM +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>
> ---
>  rust/kernel/id_pool.rs | 69 ++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 69 insertions(+)
> 
> diff --git a/rust/kernel/id_pool.rs b/rust/kernel/id_pool.rs
> index 384753fe0e44..eb911a0e3217 100644
> --- a/rust/kernel/id_pool.rs
> +++ b/rust/kernel/id_pool.rs
> @@ -4,8 +4,14 @@
>  
>  //! 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;
> +use crate::ptr::Alignment;
>  
>  /// Represents a dynamic ID pool backed by a [`BitmapVec`].
>  ///
> @@ -240,6 +246,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`.
> +    ///
> +    /// The start of the returned area is a multiple of `align`.
> +    ///
> +    /// 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: Alignment,
> +    ) -> Option<UnusedArea<'_>> {
> +        let start = self.map.next_zero_area(offset, count.get(), align)?;
> +        // INVARIANT: `next_zero_area()` returns None or a start with `start + count <= map.len()`.
> +        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(range.start, range.len());
> +    }
>  }
>  
>  /// Represents an unused id in an [`IdPool`].
> @@ -287,6 +320,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,
> +}

So, the compilation message refers the "ID range", not the UnusedArea.
To me, this 'unused' language is confusing. What should I do with the
area that I just allocated? Drop the 'unused' one and create the 'used'?

Can you rename it to id_range please? Then the API would look more
consistent, at least to me.

> +
> +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()

So maybe implement the find_acquire() method? In the caller you
serialize it with:

        let mut ids = self.inner.lock();

Is it possible to pass this down to the suggested find_acquire()? In
my experience, having non-atomic sequence of find + acquire that
requires the external locking is the recipe for troubles.

> +    #[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(range.start, range.end - range.start);
> +        range

From hierarchy perspective, the UnusedArea wraps the Range, and
passing the Range to the higher layer breaks the hierarchy. If you
follow my suggestion, the hierarchy will be enforced stricter:

        ChannelIdRange -> IdRange-> Range

instead of  

        ChannelIdArea -> UnusedArea-> Range
                      |
                      -> Range

Or I misunderstand the concept of the UnusedArea?

> +    }
> +}
> +
>  impl Default for IdPool {
>      #[inline]
>      fn default() -> Self {
> 
> -- 
> 2.55.0

  reply	other threads:[~2026-08-12 21:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12  8:51 [PATCH v5 0/5] rust: Add support for reserving of ranges of IDs Eliot Courtney
2026-08-12  8:51 ` [PATCH v5 1/5] rust: bitmap: use function-level cfg on kunit test Eliot Courtney
2026-08-12 22:23   ` Yury Norov
2026-08-12  8:51 ` [PATCH v5 2/5] rust: bitmap: restrict bitmap length to at most i32::MAX Eliot Courtney
2026-08-12 19:44   ` Yury Norov
2026-08-12  8:51 ` [PATCH v5 3/5] rust: bitmap: add contiguous area operations Eliot Courtney
2026-08-12 20:31   ` Yury Norov
2026-08-12  8:51 ` [PATCH v5 4/5] rust: id_pool: add contiguous area allocation Eliot Courtney
2026-08-12 21:16   ` Yury Norov [this message]
2026-08-12  8:51 ` [PATCH v5 5/5] gpu: nova-core: add ChannelIdPool Eliot Courtney
2026-08-12 22:18   ` Yury Norov

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=anzitCSFv28wKWeX@yury \
    --to=ynorov@nvidia.com \
    --cc=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=airlied@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=apopple@nvidia.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=burak.emir@gmail.com \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ecourtney@nvidia.com \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=nova-gpu@lists.linux.dev \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tamird@kernel.org \
    --cc=tmgross@umich.edu \
    --cc=ttabi@nvidia.com \
    --cc=work@onurozkan.dev \
    --cc=yury.norov@gmail.com \
    --cc=zhiw@nvidia.com \
    /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