From: Alice Ryhl <aliceryhl@google.com>
To: Burak Emir <bqe@google.com>
Cc: "Yury Norov" <yury.norov@gmail.com>,
"Kees Cook" <kees@kernel.org>,
"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
"Viresh Kumar" <viresh.kumar@linaro.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"Gustavo A . R . Silva" <gustavoars@kernel.org>,
"Carlos LLama" <cmllamas@google.com>,
"Pekka Ristola" <pekkarr@protonmail.com>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH v14 0/5] rust: adds Bitmap API, ID pool and bindings
Date: Thu, 14 Aug 2025 08:05:47 +0000 [thread overview]
Message-ID: <aJ2Y21Yjs3a0CnAo@google.com> (raw)
In-Reply-To: <20250813153548.1650533-1-bqe@google.com>
On Wed, Aug 13, 2025 at 03:35:41PM +0000, Burak Emir wrote:
> This series adds a Rust bitmap API for porting the approach from
> commit 15d9da3f818c ("binder: use bitmap for faster descriptor lookup")
> to Rust. The functionality in dbitmap.h makes use of bitmap and bitops.
>
> The Rust bitmap API provides a safe abstraction to underlying bitmap
> and bitops operations. For now, only includes method necessary for
> dbitmap.h, more can be added later. We perform bounds checks for
> hardening, violations are programmer errors that result in panics.
>
> We include set_bit_atomic and clear_bit_atomic operations. One has
> to avoid races with non-atomic operations, which is ensure by the
> Rust type system: either callers have shared references &bitmap in
> which case the mutations are atomic operations. Or there is a
> exclusive reference &mut bitmap, in which case there is no concurrent
> access.
>
> This series includes an optimization to represent the bitmap inline,
> as suggested by Yury.
>
> We ran a simple microbenchmark which shows that overall the Rust API
> can be expected to be about 4.5% slower than C API.
>
> We also introduce a Rust API in id_pool.rs that would replace
> dbitmap.h from the commit referenced above. This data structure is coupled
> with the bitmap API and adds support for growing and shrinking, along
> with fine-grained control over when allocation happens.
> The Binder code needs this since it holds a spinlock at the time it
> discovers that growing is necessary; this has to be release
> for performing a memory allocation with GFP_KERNEL that may cause
> sleep. We include example doctests that demonstrate this usage.
>
> Thanks everyone for all the helpful comments, this series has improved
> significantly as a result of your work.
Thanks a lot for doing this, Burak! I gave it a spin locally on
v6.17-rc1, and it seems to work.
Alice
next prev parent reply other threads:[~2025-08-14 8:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-13 15:35 [PATCH v14 0/5] rust: adds Bitmap API, ID pool and bindings Burak Emir
2025-08-13 15:35 ` [PATCH v14 1/5] rust: add bindings for bitmap.h Burak Emir
2025-08-13 15:35 ` [PATCH v14 2/5] rust: add bindings for bitops.h Burak Emir
2025-08-13 15:35 ` [PATCH v14 3/5] rust: add bitmap API Burak Emir
2025-08-13 15:35 ` [PATCH v14 4/5] rust: add find_bit_benchmark_rust module Burak Emir
2025-08-13 15:35 ` [PATCH v14 5/5] rust: add dynamic ID pool abstraction for bitmap Burak Emir
2025-08-14 8:05 ` Alice Ryhl [this message]
2025-08-14 17:12 ` [PATCH v14 0/5] rust: adds Bitmap API, ID pool and bindings Yury Norov
2025-08-15 7:36 ` Alice Ryhl
2025-08-26 13:58 ` Alice Ryhl
2025-08-26 23:58 ` Yury Norov
2025-08-27 6:34 ` Alice Ryhl
2025-09-03 20:23 ` 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=aJ2Y21Yjs3a0CnAo@google.com \
--to=aliceryhl@google.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bqe@google.com \
--cc=cmllamas@google.com \
--cc=gary@garyguo.net \
--cc=gustavoars@kernel.org \
--cc=kees@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=ojeda@kernel.org \
--cc=pekkarr@protonmail.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=viresh.kumar@linaro.org \
--cc=yury.norov@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.