+Carlos On Tue, May 27, 2025 at 4:43 PM Yury Norov <[email protected]> wrote: > > On Mon, May 26, 2025 at 03:01:29PM +0000, Burak Emir wrote: > > 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. > > Here I'm lost. In the other email you say: > > > You also commented on the API. The weirdness of the API is all due to > > the separating "request to shrink/grow" from allocation. > > Since allocation can happen while other threads may mess with the id > > pool, one has to double check that the request to shrink/grow still > > makes sense. > > And here you say: > > > there is a > > exclusive reference &mut bitmap, in which case there is no concurrent > > access > > So to me it sounds like if I want to resize, I just allocate a new bitmap, > take this exclusive reference, copy IDs, swap the pointers in > corresponding class, and that's it. What did I miss?
The two emails are about two related but different things: 1. the bitmap API which uses kmalloc with GFP_KERNEL, and what you suggest could be done with &mut references 2. the id_pool and its fine-grained API that permits controlling the time of allocation, which is used in binder which relies on a spinlock. My limited understanding is that calling kmalloc w/ GFP_KERNEL while holding a spinlock is not good, since the kmalloc may sleep. You can see this "first unlock, then alloc, then lock again" pattern in binder code here: https://github.com/torvalds/linux/blob/15d9da3f818cae676f822a04407d3c17b53357d2/drivers/android/binder.c#L1099 cheers, - Burak
