From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7BB5E7719E for ; Mon, 13 Jan 2025 10:04:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 05E636B007B; Mon, 13 Jan 2025 05:04:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 00E146B0083; Mon, 13 Jan 2025 05:04:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF0296B0085; Mon, 13 Jan 2025 05:04:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id BDFEE6B007B for ; Mon, 13 Jan 2025 05:04:52 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3ECD31C909D for ; Mon, 13 Jan 2025 10:04:52 +0000 (UTC) X-FDA: 83001994824.12.897C563 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) by imf06.hostedemail.com (Postfix) with ESMTP id 59EF718000E for ; Mon, 13 Jan 2025 10:04:50 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=JQmai5eY; spf=pass (imf06.hostedemail.com: domain of aliceryhl@google.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736762690; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cTnHrkrCK9aVruiggOEjuJFURydlBondtCGki6zspaI=; b=ZR7e3ygz8ACcZh7Unw/0CmZ6b5CFHvWfW0Er/sxbS9t9cL9XyNdnG6JTq7P07C3F/uqjsM I0yCE78fXM3o/pgXMJhShIsUwdSFrKfNu6mvKAHPwnaOuoGVy0RBMeECDxmZlB6sltYkZv 5Mf2sYBd1al5EzgvYl/ceW4CaeaCcsA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736762690; a=rsa-sha256; cv=none; b=0LhxrAiBw8NtCz51LhqCNnwOXbpHPgwIQRVQz/wOaj1RpAXAsrIvIqUYyQ53vmZs2MPJJi 0X70/AqOSHu/4pMnFxlRNro35LMkGucCRr1jLnF7NbCRfJoSc+frzn22mEvEIVH8yU7dg4 Vrn3rn2y4PGqjAzuodb0Rj5KOZUX4po= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=JQmai5eY; spf=pass (imf06.hostedemail.com: domain of aliceryhl@google.com designates 209.85.128.54 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-436341f575fso41799405e9.1 for ; Mon, 13 Jan 2025 02:04:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736762689; x=1737367489; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=cTnHrkrCK9aVruiggOEjuJFURydlBondtCGki6zspaI=; b=JQmai5eYqnjcFpCrvZU0stoxgnkeK8NFM3rNtZ4j+qk8Ex7fgneotp9qWzUKPErhlA ku1nVhr6qWHqISP+q/dvm7223YlsiJGZxk3iJigOfp09ANxPeGrglb7+mNzE64/9tkbk dIgt7qoLoHCvIXi0/CbTUq2vqkCx3a5Sl/hPAARdyT+UOe3mhLdViuNpao7sllphGJcJ lJR1qYApr2/ZEzY1vNuaIlbugIo51WM/cfmshOsYsGpN+F5RKUyG+FvqzI1gjo5jVDIZ 0YLrcXNRbwLZW0nhNTqlKF9zKnuceGSfcHOwZuaNyxCVvlHpDfh5KVUKWWxAsXRZnqH6 ONJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736762689; x=1737367489; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=cTnHrkrCK9aVruiggOEjuJFURydlBondtCGki6zspaI=; b=USB/6kU7DaWAdPHy9a3WEfDz1506q80hgdK0+AiT/mvZU9WIxEFkr9q09mCzIhHlsM geTNr80Xh4Yg9OciujW+Ar0ZhZ15ReIPmv8crKwP6G5Kge7QA3dkwa7RuZbO9zvA5yMV Ui+hNBKMaD9MuRghvQZHUUrRg+VOzRZcJKClnKENplzMieBgIQxZ5KsCZ3otR9JgXw9B XswGhPxuFcggFdS7x0UIAwF23YJY5cTO9y5pJ5D86JSfAN0Ee5joiZ5Bg8kfUwUf8/5V J6mUtiq9BxTT5/5+LkhwTizQW+iBuMDurzqxYImcJW3GqnfkiZuaD6pglqQCP2D1eHyT PRqw== X-Forwarded-Encrypted: i=1; AJvYcCUK543X9GCeNqOZ48aGj1pigB2mBiVmxrmsAxwgCEw1dc3iRdmBqC1hfKQ6GfYLno8x9xBUv49O9A==@kvack.org X-Gm-Message-State: AOJu0YxMLPQcPgysO3ZNg6XdZCSaOR6SSaJo/lNAvYrailwTRJ6LyAMp YXDKfKsOLZwPNoeyuP9QWpSsb5DpX38QzwdPCohU8vmBmlz1sJH6AZE2N+itXnVx+wINZlE66qd mHwJyFnU55OYm52qhbGIkmRDAVwqdnph4idHn X-Gm-Gg: ASbGncu3q59ZrSPWZORuqRXqpvhwg55F9bV4kAJPpW3+RGl5AACOAwFilumNOWHoRbd 7WfyMnJOBm7iDdp9x0HojhFDPNLSCpWP1JueRyv2y5QbQKKA7bpQnCWdqJ41w3c/CYCPH X-Google-Smtp-Source: AGHT+IEb2/iBvWA25oOoS/cFn89nZ6lRBPbi7b/Zh2yp5GE/04Ymcj9QFQdZ3E/rVz9ACHhaVdJLRZA7ErZyMXViZ4k= X-Received: by 2002:a5d:64c9:0:b0:385:e88a:7037 with SMTP id ffacd0b85a97d-38a872fc182mr16642759f8f.6.1736762688566; Mon, 13 Jan 2025 02:04:48 -0800 (PST) MIME-Version: 1.0 References: <20241211-vma-v11-0-466640428fc3@google.com> <20241211-vma-v11-4-466640428fc3@google.com> <87jzbzbxrk.fsf@kernel.org> In-Reply-To: <87jzbzbxrk.fsf@kernel.org> From: Alice Ryhl Date: Mon, 13 Jan 2025 11:04:36 +0100 X-Gm-Features: AbW1kvbm9xIsdtcFoxgdgDqzPKAGTDok7KbPejqS7tX7dbZZUZ1FP9FO-qibG3A Message-ID: Subject: Re: [PATCH v11 4/8] mm: rust: add lock_vma_under_rcu To: Andreas Hindborg 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 , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Trevor Gross , linux-kernel@vger.kernel.org, linux-mm@kvack.org, rust-for-linux@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 59EF718000E X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: abcrufk4xdpz3h1asrm1msqz979igysc X-HE-Tag: 1736762690-655789 X-HE-Meta: U2FsdGVkX1//NQzIw7icvX4Zo+9TAs08zVIXsaKbxlatp6xGMJsDoO4EqNp/HfnnVk4oBFfSy6Dqbfpq6WMwU2aFJZUhXmPGfc3cvaGbiQ2+l4bN7F8yp0K9QMs+MabMQ3zuXkducRL3/DbvssSs7AyVGkb0yYnHjMDATIWmMFDd57UdGH1K7ed6eDn7Zik87jwPApbpB3OWzClK6pH6Sl26UMKDJaBp8CO354isNKvkONpRHP/5KmNby0r7z5bc8zFyoCDg4TilHaXIyCqjXpMauGCpsHd0OhP3kieaw2MAmhses07Z75IQqepv/lT2HFFjf8uAkBS66olUm2yUsrYfeU++ODaqTSaAHUVWWJG/pCxu31SYUExem5eyo4quFgdinQ7z9CCaG5gBwyGk4T1nFqwHI8pbnnyXWzMTMybM/YKojEKwRBEpSiHuPhSdRlQcbYoNn+zYz1S3v8wiGGuLpJNxFHiJcsVrBVGxK6WOO8y6r9+q0zH7dXZPwqLNp7B47NQWZo7nM/G12TuVI0Q8cJV7CSTCcPayqW7YnL6I4YaHSIVouE4RLF8cFvUu1mB+SA45VUSjFyZreQ60InszfGdQ0nitt8GM7aCWammC8Prg96EUVD0CUyErakm+jZ5n4c8HYEZIEP2eLqCTuIFWtlzzXYOWf+hpWHAStBuvTBE7PBzJZi9YxjYiVjprkxAXYoiNE7I9dUePTbEoYmxAk7/IiWf2ZrefCnqRQhASqcwf+GlA4hmRe9axSwQ+LLr5x32Gp1Ui/DS4afLNPz4sabK5a7GAPmY22SMP27b3IkTqVp/eeAwQLj2rUDvj9Yc1L0ulL8zBX/M+dDHd3h0aif4ZTckDA/lNjuvh7kzqBxCMZF9GUEVbNGDwarXTKyKyVxa+23tbH1UfvV1xEm4DN9RobAerEHm423pK/hJNEqBiZugBY/VYGxVoNaKP+qCKBJXvrG7l16XSD7H RR5phLRE w/ia47KwOIXxpyCpKkfLciHtbqisG8bEHhYeq5QphVNWy8b4yxelivZO4lLDSKT//KgEfFYpchurZ0hq8KShk6/qkFO0sWMzR5ZJUObwa8MkSR7WkjWV8iOYo+fzwtSqQfIDu5QgXklTkhzAoHUlFxWoZjDS5juQg0jHWt6gt5aXJOdkLrIHihqGE6CZhz1YhW0Za7SsHcJuncCPsMXDplinNAIluQkiVBDgBGZjAld9kwN/0m2kWqP9SI6N/k+wzqbGtwAKnx/oS4lue7u983qXOocSfx32Xfcpw7mk3M4WgjO3a7ulcBkX7sUjkWiK2iIAC43awOjTa3aH7/c2m/eJdo2/y4MZ7+8hmeMk3FlGSZownbkwNzETKxRfZasG07VTi X-Bogosity: Ham, tests=bogofilter, spamicity=0.376191, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Dec 16, 2024 at 3:50=E2=80=AFPM Andreas Hindborg wrote: > > "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 calle= d > > 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::m= m_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 the= re 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 alway= s okay given an mm where > > + // `mm_users` is non-zero. > > + let vma =3D unsafe { bindings::lock_vma_under_rcu(self.as_= raw(), vma_addr as _) }; > > Is `as _` the right approach here? We can drop it once the FFI integer types are fixed. It's late in the cycle, so this patch probably won't make it for 6.14. This means I can remove the casts entirely before this is merged. Otherwise we can remove them in a follow-up. Alice