From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3EFC432B123 for ; Thu, 6 Aug 2026 09:01:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.72 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786006886; cv=none; b=PmDCGV0xouyeO7B/rmfhw58xSaXWQOulOmuIBOLAUoBpr3M6C9rmdThdAH9pNVJI/9zgGH9JSvy+WT4M0gJB1nY6+237BB3I2YRsVZaww2GJN+aFJKBxJi6N/stqx9+ykfFjc+UpAZs5aTjmLxpB8o1aMX6jE+wJaFGl4CxeAag= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786006886; c=relaxed/simple; bh=PIMd/E8O88l1Ksd8pkf8uK+AsYWe38tRqgOEus44zLI=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=itRK2CDOFmAp99g/n8k3e/fD9zloHZ4pqb22HIZfefL4BEi4dV7jedQI24sgbKt+02tqniuUgsBBKQKO4mMzQj1JGO2NhB459pa0NRN/62HMB4aqxwHbOFenGCmeConNIfPNcsiY8YC60fprC4Nd0Ms33r7LabP+pkJRUCY4cCk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=g5yh/975; arc=none smtp.client-ip=209.85.128.72 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="g5yh/975" Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-49554715277so17347065e9.1 for ; Thu, 06 Aug 2026 02:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1786006883; x=1786611683; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=F/93S3EG0iH5GDBSu6eSWwzd/AjIJb7wv7fg8IFc6zI=; b=g5yh/975YKw23XlQSCcH4wasteQZUgxbYSjpCOSuOYW+QGRFb0anptD2nNPh36oAWf 1BvMNnBObNkR/0iBd4dn5SqL4CnJGq7T5IMe/34aIJM2TQCzS8JJhv46w6jOdw+kukI7 n5WB8NUPkaznTjFheK5Q9nJyWy98XSk8Z3YtWfAm9ROGaPh+ClqVNonB05jrDJ05/uGO c5k6YhdGLYAMFsLlUrpAmc/sW+wBBe0Cyx+HjUPLhMGQSk9sMU3IMEOigrMLD+6dWADY hp4WyxeGfshkY441klbWwpyNq4sALN6Q1bQ7sBWcvOMhKUbr3M7N4hzYfbgpKGrP/p1R /gLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786006883; x=1786611683; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=F/93S3EG0iH5GDBSu6eSWwzd/AjIJb7wv7fg8IFc6zI=; b=VFt/DHn1gsX0qS2yRiCK9l2hXft6eTQpbU4Qaly91giGngNKu7O7g28sHJHIQ27JC4 KhkVJRQZJLB92UBKTwPCL1NrGD/LrBlTaP/REqBroM7vHm27vdn9kgZqDma9mlArzDVf AKcn72j3a6xOl98uG29iteQgNA/Q07fWUOdg3+EPY2re3JLz63IIMIpNIT3Hbqq341Il 0SiKKEcalLOuHBjpDKhbxgErai0i46KFTYJhHNkvBo35UhrdfHgZWEfncqpxsZonl+SS AE782T/qhXN6utL+aSeMmpLSgb5Xw/s2GU54VTULevCiJ2LQ/5WHucz4D4oPr6HMs7If H6lQ== X-Forwarded-Encrypted: i=1; AHgh+RrNkat3Yhd2OHPahp5Q1rVrLjmHou0MWAWbv2qlK/GYJQrFmw+XK/yvCvTnvfBM2GNITQ+lRdOS6kDVSk8=@vger.kernel.org X-Gm-Message-State: AOJu0YxhYPDaSto7kliP3jw7ajL1C+XXpiTSyCzdYNTwpYIP5HDdGiQ/ CHXJXaGTU+hVSmVcdjntQIlGqagB+FngkNB8PwBH95wShJKSr4Lsvcv+i29Tf7ZIHX7ah/lYZnP ipM/R7GwLIMutqxYPKg== X-Received: from wmsu14-n2.prod.google.com ([2002:a05:600c:c3ce:20b0:495:72a8:661f]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:3ba6:b0:499:48be:3189 with SMTP id 5b1f17b1804b1-4994e6c065fmr169340255e9.0.1786006882478; Thu, 06 Aug 2026 02:01:22 -0700 (PDT) Date: Thu, 6 Aug 2026 09:01:19 +0000 In-Reply-To: <20260805152752.1924434-1-zhangbo56@xiaomi.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260805152752.1924434-1-zhangbo56@xiaomi.com> Message-ID: Subject: Re: [RFC PATCH 0/1] binder: switch alloc->mutex back to spinlock From: Alice Ryhl To: Bo Zhang Cc: gregkh@linuxfoundation.org, cmllamas@google.com, arve@android.com, tkjos@android.com, christian@brauner.io, surenb@google.com, baohua@kernel.org, zhanghongru06@gmail.com, linux-kernel@vger.kernel.org, Bo Zhang Content-Type: text/plain; charset="utf-8" On Wed, Aug 05, 2026 at 11:27:51PM +0800, Bo Zhang wrote: > Hi, > > This patch switches the binder_alloc mutex back to a spinlock to reduce > transaction latency. > > Background: > > Commit 7710e2cca32e ("binder: switch alloc->mutex to spinlock_t") > originally converted the mutex to a spinlock for performance. It was > later reverted by commit 8b52c7261e04 in preparation for commit > d1716b4b78fb ("binder: concurrent page installation"), which states: > > "zap_page_range_single() is called under the alloc->mutex to avoid > racing with the shrinker." > > Analysis: > > After inspection, holding the lock across zap_vma_range() in the shrinker > path is unnecessary. The page installation side does NOT hold alloc->mutex, > so the mutex provides no mutual exclusion between install and zap. The > actual synchronization is guaranteed at the PTE lock level: > > 1. vm_insert_page() acquires the PTE lock to set the PTE entry. > 2. zap_vma_range() acquires the PTE lock to clear the PTE entry. > 3. On race conditions, the install path calls binder_page_lookup > which uses get_user_pages_remote() to atomically pin the page > under PTE lock, preventing use-after-free regardless of zap timing. > > The alloc lock only needs to protect buffer metadata (rb-trees, pages > array, LRU list operations), all of which are non-sleeping and complete > before zap_vma_range() is called. > > By moving spin_unlock() before zap_vma_range() in the shrinker path, we > can safely convert back to a spinlock. > > Performance (binderThroughputTest, Qualcomm SM8850, 2 workers, 10 runs): > > mutex spinlock > throughput: 27k-59k iter/s 79k-84k iter/s (~80% improvement) > average: 0.031-0.068ms 0.022-0.023ms (~45% reduction) > P99: 0.088-0.148ms 0.050-0.062ms (~55% reduction) > variance: high (2x spread) low (stable) > > The spinlock eliminates priority inversion where low-priority tasks > holding the mutex sleep, blocking high-priority binder transactions. > > Looking forward to feedback on this analysis. This will not work due to the following race condition between T1 and T2: T1 binder_alloc_free_page() removes the page from alloc->pages T2 binder_alloc_new_buf_locked() runs T2 binder_install_single_page() gets -EBUSY T2 binder_page_lookup() looks up the page in the vma T1 binder_alloc_free_page() calls zap_vma_range() In this scenario, T2 looks up a page that it expects to be "pinned" and not removable by the shrinker, but the shrinker zaps it anyway. Today this cannot happen because binder_alloc_new_buf_locked() runs under the mutex, which ensures that zap_vma_range() finishes removing the page before binder_install_single_page() runs. Alice