From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE502145A05; Mon, 16 Dec 2024 14:50:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734360657; cv=none; b=SJHSg0hB1+seQ8Yv/dDriRK6KhUdeOnXV0ZFRe34rFAN8s6QmqONTC4juoWIaqoCKDI8ysR1RLMNKVjlPf5jwndbQhBPaC/BxnKeDUyduGIC8xW9dKfDDO9TBF5F7hAVEHYqg/rw/4HNQq9cQFZ5wn9SsBYUWrpn5ASyKYhvj60= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734360657; c=relaxed/simple; bh=FHSKQmzPdFG9CKTMPQ6TI+GuboZTe/7QRXLSQ47Adp4=; h=From:To:Cc:Subject:In-Reply-To:Date:Message-ID:References: MIME-Version:Content-Type; b=Pa7yZI1qxdMz6xb7jg4eL3frmmlYzSArAnfB/BwtxQBohRYvf5pYItQPXmHdXGsgI+ifcGOweBoCrucQ8a1CPp3/gSm15pgL5oCcFkQlK9QQageVoVJAN0C/WdGmt7Kqbj1dIjIqN00DLoMkudvTxDfEItUqOtL8mJzbb7FUUY0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iY3MHIeD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iY3MHIeD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B31E7C4CED0; Mon, 16 Dec 2024 14:50:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734360657; bh=FHSKQmzPdFG9CKTMPQ6TI+GuboZTe/7QRXLSQ47Adp4=; h=From:To:Cc:Subject:In-Reply-To:Date:References:From; b=iY3MHIeD+eKZcKR6936M4JiHCd9w4+Hm6gJ2fTm9HF2TC0lPxlMw4j/M0qkLF9lGE bp4tsX6m9Qw8mZjQSxjvufNA24PnvzlMEwDuLt2lsAxhb+8IpN+aVZBzVCCTtekdnx MJFeWJ0LlVHulmrQ9Ye7gloOmVeQPgUmZKZFN/YEzh+htZ2QhzF3i2Bfjtr2rNhM2E gd4nvxd4p2+wYLHlqZfp14Qod2FuXhB6u0tsMeorMiJIyzWsa1DvqEQevMstDQ4nm7 6earhRgnx37C5DVA0YN4ihLtUxqXHGvmq7peJk6GsgP+qAZOY876Zdj3i6wcCs6g4y 8zufe36yAuQvw== From: Andreas Hindborg To: "Alice Ryhl" Cc: "Miguel Ojeda" , "Matthew Wilcox" , "Lorenzo Stoakes" , "Vlastimil Babka" , "John Hubbard" , "Liam R. Howlett" , "Andrew Morton" , "Greg Kroah-Hartman" , "Arnd Bergmann" , "Christian Brauner" , "Jann Horn" , "Suren Baghdasaryan" , "Alex Gaynor" , "Boqun Feng" , "Gary Guo" , =?us-ascii?Q?=3D=3Futf-8=3FQ=3FBj=3DC3?= =?us-ascii?Q?=3DB6rn=3F=3D?= Roy Baron , "Benno Lossin" , "Trevor Gross" , , , Subject: Re: [PATCH v11 4/8] mm: rust: add lock_vma_under_rcu In-Reply-To: <20241211-vma-v11-4-466640428fc3@google.com> (Alice Ryhl's message of "Wed, 11 Dec 2024 10:37:08 +0000") Date: Mon, 16 Dec 2024 13:47:11 +0100 Message-ID: <87jzbzbxrk.fsf@kernel.org> References: <20241211-vma-v11-0-466640428fc3@google.com> <20241211-vma-v11-4-466640428fc3@google.com> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain "Alice Ryhl" writes: > Currently, the binder driver always uses the mmap lock to make changes > to its vma. Because the mmap lock is global to the process, this can > involve significant contention. However, the kernel has a feature called > per-vma locks, which can significantly reduce contention. For example, > you can take a vma lock in parallel with an mmap write lock. This is > important because contention on the mmap lock has been a long-term > recurring challenge for the Binder driver. > > This patch introduces support for using `lock_vma_under_rcu` from Rust. > The Rust Binder driver will be able to use this to reduce contention on > the mmap lock. > > Acked-by: Lorenzo Stoakes (for mm bits) > Reviewed-by: Jann Horn > Signed-off-by: Alice Ryhl > --- > rust/helpers/mm.c | 5 +++++ > rust/kernel/mm.rs | 56 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 61 insertions(+) > > diff --git a/rust/helpers/mm.c b/rust/helpers/mm.c > index 7b72eb065a3e..81b510c96fd2 100644 > --- a/rust/helpers/mm.c > +++ b/rust/helpers/mm.c > @@ -43,3 +43,8 @@ struct vm_area_struct *rust_helper_vma_lookup(struct mm_struct *mm, > { > return vma_lookup(mm, addr); > } > + > +void rust_helper_vma_end_read(struct vm_area_struct *vma) > +{ > + vma_end_read(vma); > +} > diff --git a/rust/kernel/mm.rs b/rust/kernel/mm.rs > index ace8e7d57afe..425b73a9dfe6 100644 > --- a/rust/kernel/mm.rs > +++ b/rust/kernel/mm.rs > @@ -13,6 +13,7 @@ > use core::{ops::Deref, ptr::NonNull}; > > pub mod virt; > +use virt::VmAreaRef; > > /// A wrapper for the kernel's `struct mm_struct`. > /// > @@ -170,6 +171,32 @@ pub unsafe fn from_raw<'a>(ptr: *const bindings::mm_struct) -> &'a MmWithUser { > unsafe { &*ptr.cast() } > } > > + /// Attempt to access a vma using the vma read lock. > + /// > + /// This is an optimistic trylock operation, so it may fail if there is contention. In that > + /// case, you should fall back to taking the mmap read lock. > + /// > + /// When per-vma locks are disabled, this always returns `None`. > + #[inline] > + pub fn lock_vma_under_rcu(&self, vma_addr: usize) -> Option> { > + #[cfg(CONFIG_PER_VMA_LOCK)] > + { > + // SAFETY: Calling `bindings::lock_vma_under_rcu` is always okay given an mm where > + // `mm_users` is non-zero. > + let vma = unsafe { bindings::lock_vma_under_rcu(self.as_raw(), vma_addr as _) }; Is `as _` the right approach here? Best regards, Andreas Hindborg