Re: [RFC PATCH v2 1/2] binder: switch alloc->mutex to spinlock for buffer metadata

[Bo Zhang]

On Mon, Aug 31, 2026 at 08:35:44PM +0800, Bo Zhang wrote:
> @@ -967,7 +967,7 @@ void binder_alloc_deferred_release(struct binder_alloc *alloc)
>  	struct binder_buffer *buffer;
>
>  	buffers = 0;
> -	mutex_lock(&alloc->mutex);
> +	spin_lock(&alloc->lock);
>  	BUG_ON(alloc->mapped);
>
>  	while ((n = rb_first(&alloc->allocated_buffers))) {

Sashiko says

"Does this conversion to a spinlock introduce an unbounded preemption
latency regression during binder teardown?

Inside this spinlock-protected section, if a buffer is marked
clear_on_free, binder_alloc_clear_buf() uses memset_page() to zero out
up to 4MB of memory. Subsequently, the function also iterates over up to
1024 pages in the same locked section, calling binder_free_page() for
each.

Could performing massive memory zeroing and over a thousand page frees
while holding a spinlock disable preemption for multiple milliseconds,
creating a latency spike on exit or crash?"

This behavior is not introduced by this series. It matches the original
spinlock implementation in commit 7710e2cca32e ("binder: switch
alloc->mutex to spinlock_t"), which was reviewed and merged upstream
(later reverted for unrelated reasons in commit 8b52c7261e04).

binder_alloc_deferred_release() is a cold teardown path, executed only
once when the binder proc is released (from binder_free_proc(), right
before kfree(proc)). It is not the hot transaction path this series
optimizes. At that point the proc has been detached and alloc->mapped is
false, so there are no concurrent binder transactions.

I've kept it aligned with the previously-accepted spinlock version to
keep this series focused on the lock split. Reducing teardown preemption
latency, if desired, would be better addressed as a separate patch.

Bo