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 01C37E77188 for ; Wed, 8 Jan 2025 12:21:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D2E96B0088; Wed, 8 Jan 2025 07:21:26 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7836D6B0089; Wed, 8 Jan 2025 07:21:26 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 624006B008A; Wed, 8 Jan 2025 07:21:26 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 424EA6B0088 for ; Wed, 8 Jan 2025 07:21:26 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 59B5AC10BA for ; Wed, 8 Jan 2025 12:21:25 +0000 (UTC) X-FDA: 82984194930.20.411B553 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) by imf22.hostedemail.com (Postfix) with ESMTP id 67859C000C for ; Wed, 8 Jan 2025 12:21:23 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=4U9VKb1O; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of aliceryhl@google.com designates 209.85.128.51 as permitted sender) smtp.mailfrom=aliceryhl@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736338883; a=rsa-sha256; cv=none; b=OeLuTbXwzE3GO4jq+osPz0hCTAUIJObr2K//ppOcWvWAePPkPsN2ewZu+aJUKQShl9WPkj dBjzYMrEAAQqdNLtPYyeT7rkS7S2R8bKcvrMkQ3BEFPKLX24E36UlDhnWrpQltMO5j1K8p XsFiD9sarkKPW7y3Xq11CZgcRAncpPw= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=4U9VKb1O; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf22.hostedemail.com: domain of aliceryhl@google.com designates 209.85.128.51 as permitted sender) smtp.mailfrom=aliceryhl@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736338883; 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=xI2Qiim8gcdicwYWfir8MoYW/kVHDh3Rzufu5nMKjxY=; b=CzyMm7deRRAijWDgLaJRyNdZL0BufNVNLepaDMw6ctaVfzCm42W03XdsNaVTD07ovh5PwQ Q3laUWNYEzRQVD/VcAHd3hBOMCE0AdGZiKoNZ8msSoVZhaWW4/p1/tEzCLTLqnkjmFxI6u mtIZhTipRJMt10iz89rVdkDoDbhmyqg= Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4363dc916ceso4886015e9.0 for ; Wed, 08 Jan 2025 04:21:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736338882; x=1736943682; 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=xI2Qiim8gcdicwYWfir8MoYW/kVHDh3Rzufu5nMKjxY=; b=4U9VKb1ONMxItph3zpjoPW2JgZJqH//PcH+DnPWrzqBdExwqbvBAojrz8c/Vf5nrDn V5MUIYIO4i4qQcod457AxcfuHG88oO5myPQ58YbRLff96EXKahK8HDphAnqoD88YIVbd Dt0kZAdCXLmHbt6agx6/RMGHKR6cIPwlxFoKfQF3WPXjNnSmnVdv/CXUN7pBLNtIOZ9L 3AqMN7VTu037e3Jq0pXZeR2RYVL1kutI9KYF4YZKOr537YJvVlpLTlEGyc/B+ApQQ6K0 H2Wd0LwLsqMmbxHJSPMwxPF2uMh5NAqJw9sgKcjCNfOUXSaY3iOtFUsX+OtHXhPHeRYq 3uCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736338882; x=1736943682; 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=xI2Qiim8gcdicwYWfir8MoYW/kVHDh3Rzufu5nMKjxY=; b=YOLAPSORzv37SeB6ecP8f+hdv6EhF16rKNXQjK2e4uatvQjiLVJg4Bxtud15MiT8Hn wt6WDIA27sFfsQre0Mwl/qqY4UzKpm5R8W9XHNi4qgVYLuWiGY3cjz5AbedJG3S5IE+7 3JMhwfrbK8iZ3pnjVGBIGXX3MwK/PGaYz/IaycyVpUOEaWJB3AvE31/2oBNXZRDMjHyq jJkXFfwxmB5KRsCdKwVC9SaZp30UZZBYiyY/K0o28CVo8SK5yFYXoTJ/Ss1iTUVcv2X6 PifU+tqXaNV/Egs968ohSlXucdSxaiFT2SrWm6r3O4ALp/dr1rReqIK7QDOc05ISNhJS Fcjw== X-Forwarded-Encrypted: i=1; AJvYcCUIgOo9urfIBBd9kM3y+FFCuY2/h6vectRTbBwuygDMSW8rGOBbXrG9KnH5DugKI48etlETcufvRA==@kvack.org X-Gm-Message-State: AOJu0YwHWQGO6579LTB/UOfZsP+ZW9XKnpxxu169qW+VQ5k5IUy1Yt4r 7cHEJExTLTYe3aEEAs8zLSUvVu1QRpup0DNOe0ML0VQyln+U0fACL9Ol2lE1VVibYaMSlMX5GK0 nEoDOMBF9Q91tMWMYIlKVN7JJnVhasHQpPebf X-Gm-Gg: ASbGncsc/VGRPFBtdhALCyVwvjcjcAC9CBfyo3I8uOlEam5pdcRJwsOMYMmSnWkspbG OWJsks8Jqpsav36sgA+1Dpm9gSNP8ZhYfYZIH+4mCRLpHygfTLdeCHGEZYMSjT/mpI/d0 X-Google-Smtp-Source: AGHT+IHztojrzFSkFDAxKutyqCxZSmSFncOQRaBDo6xDYYMDtTeZFL+GYNfpCD1T8zBhKQ5iBqUzzDMNVBmrs6Rtz6Y= X-Received: by 2002:a05:6000:1541:b0:385:fa30:4f87 with SMTP id ffacd0b85a97d-38a85ddc5bemr2800789f8f.0.1736338880225; Wed, 08 Jan 2025 04:21:20 -0800 (PST) MIME-Version: 1.0 References: <20241211-vma-v11-0-466640428fc3@google.com> <20241211-vma-v11-2-466640428fc3@google.com> <874j33ddxt.fsf@kernel.org> In-Reply-To: <874j33ddxt.fsf@kernel.org> From: Alice Ryhl Date: Wed, 8 Jan 2025 13:21:08 +0100 X-Gm-Features: AbW1kvat9FEGpb2nRkzTm_D0loLbXycItZanw6K__7X-P_mJksbydnGOPToUHeU Message-ID: Subject: Re: [PATCH v11 2/8] mm: rust: add vm_area_struct methods that require read access 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-Stat-Signature: efyacbzt4otdn7zxfppkkun16jr334dh X-Rspam-User: X-Rspamd-Queue-Id: 67859C000C X-Rspamd-Server: rspam08 X-HE-Tag: 1736338883-87545 X-HE-Meta: U2FsdGVkX1/kJi4qK9UfP/ddDT4M0xfgze1Obj5lVTgmDyiPVLJCZhGTI8Dc1h/loByli134xsjufDLL0VSmnTE/pkR8qSynF+3o7hLCyyFZHEs/9/BxYBjsq8T0fXWk+VoLz/nsIPeZtTokwSM/+TR05qBbAbhkt+8kpC6HapfFb28WNmLAQr6ZpRS1xvzj7pxrxRgdcBA63rB3qWBH1i3/AuRyzuSMWIlfwvp8XapwQcGE/x1PQnHnGacEjhrlmtum2qCQAAuuv1z2eGSOine249EOpu3G/c9fNDPdKPubIhJw1gWFBHeov3inESMBkQpasnISe5Ug/rfyEKqaq+8lmlZbK5cmC/1zxl8NFUrbpedgTqSF0k5sdq2O3SU7Qn64uN7l/UA/d0O0qVqR/Qk86XTtIwnlb1fDOK503rB/lMcZ6pipLUSKLScb4GxrN8zXYaBomboFfeiCcHFRaCh0BjyTrZKqVWP/fAHHJZIDgklc5e9htfXDRXzsJfAOP7NXqem/dLOG7vfmi+b2tzAZ/7ZSgpLWosAVbA/IBRBbkVn5h5/dhZJ6Wtz4v+HVOYrOFjzFFsMOmSBC1kjB9RffkseBZWjKpqUdh0Q1daWilT5vU9tAWObL+BUuzLSBGRagGlfMU3YSLPh/ZDSEi/FtQ5rowbrQCIHwqxBKGX1tH42KpWoOkMJnPtQW689IInT3lBSkM4JxUvOcjz7pcvQll16MThgWlSSSHfxe2lSwdaSbcV+1CvkTIRSO3/qy1v2tsHDqjL/CbPSKjjNsPcPSbj2okGqDqaGqVMmXVmwzxWwzyJbWLKzkMcojTHsbmyGJSINy1PMUhUvoYihK8+rqACYAjb3m894nU/wA2f3j8hFqV0RuCv9SxUP7f4+/0/06qd2Xx6F+P3i7uocC/lqHC6H6deK71iflKqu0+5u2d+afhMyUTWtwrEMcog5u8+UcBLOW6gdOZgnIR2u 6niyLrim cOperpV+FmhFRSidSzLQ4UXXcugULj6A+V+tiSYvkPOEL7a1jCYqOGK5BLuXPEqho3OEVzUwFDknfxnda0qVxplFhGqRiOqDMFko/XhLDv0j4LXnZH5pXohcHXf0Ku/ccf8yJUcwdhvK/S9d8SqLmP9ZzMDIuIOym6W2no97iNP5QWDY18mCIh2mrVJRwvfY8TAnzF8tgrnk63hNa1VnIoiY9G/UgHTMkprzUN08Otjth0Cl1Y2ctJShZpUG8XuUsz9Q5CdJ5maF+3wAuTHwveUTDmwAUFvlUtTvBzW2+Zro/m4q3pLWyCBlk6cRcJTl0LDdnvaPLdlualbfq0kUdWeLQl4GX/4wvePffF14i3G9jHf9Kx3AFLysMLeI5U7dCPfII X-Bogosity: Ham, tests=bogofilter, spamicity=0.366579, 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:51=E2=80=AFPM Andreas Hindborg wrote: > > > Hi Alice, > > In general, can we avoid the `as _` casts? If not, could you elaborate > why they are the right choice here, rather than `try_into`? They're not fallible and will go away once we merge the patch that makes integer types match better. > Other comments inline below. > > "Alice Ryhl" writes: > > > This adds a type called VmAreaRef which is used when referencing a vma > > that you have read access to. Here, read access means that you hold > > either the mmap read lock or the vma read lock (or stronger). > > > > Additionally, a vma_lookup method is added to the mmap read guard, whic= h > > enables you to obtain a &VmAreaRef in safe Rust code. > > > > This patch only provides a way to lock the mmap read lock, but a > > follow-up patch also provides a way to just lock the vma read lock. > > > > Acked-by: Lorenzo Stoakes (for mm bits) > > Reviewed-by: Jann Horn > > Signed-off-by: Alice Ryhl > > --- > > rust/helpers/mm.c | 6 ++ > > rust/kernel/mm.rs | 21 ++++++ > > rust/kernel/mm/virt.rs | 191 +++++++++++++++++++++++++++++++++++++++++= ++++++++ > > 3 files changed, 218 insertions(+) > > > > [cut] > > > diff --git a/rust/kernel/mm/virt.rs b/rust/kernel/mm/virt.rs > > new file mode 100644 > > index 000000000000..68c763169cf0 > > --- /dev/null > > +++ b/rust/kernel/mm/virt.rs > > @@ -0,0 +1,191 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > + > > +// Copyright (C) 2024 Google LLC. > > + > > +//! Virtual memory. > > Could you add a bit more context here? > > > + > > +use crate::{bindings, mm::MmWithUser, types::Opaque}; > > + > > +/// A wrapper for the kernel's `struct vm_area_struct` with read acces= s. > > +/// > > +/// It represents an area of virtual memory. > > +/// > > +/// # Invariants > > +/// > > +/// The caller must hold the mmap read lock or the vma read lock. > > +#[repr(transparent)] > > +pub struct VmAreaRef { > > + vma: Opaque, > > +} > > + > > +// Methods you can call when holding the mmap or vma read lock (or > > strong). They must be usable no > > typo "strong". > > > +// matter what the vma flags are. > > +impl VmAreaRef { > > + /// Access a virtual memory area given a raw pointer. > > + /// > > + /// # Safety > > + /// > > + /// Callers must ensure that `vma` is valid for the duration of 'a= , and that the mmap or vma > > + /// read lock (or stronger) is held for at least the duration of '= a. > > + #[inline] > > + pub unsafe fn from_raw<'a>(vma: *const bindings::vm_area_struct) -= > &'a Self { > > + // SAFETY: The caller ensures that the invariants are satisfie= d for the duration of 'a. > > + unsafe { &*vma.cast() } > > + } > > + > > + /// Returns a raw pointer to this area. > > + #[inline] > > + pub fn as_ptr(&self) -> *mut bindings::vm_area_struct { > > + self.vma.get() > > + } > > + > > + /// Access the underlying `mm_struct`. > > + #[inline] > > + pub fn mm(&self) -> &MmWithUser { > > + // SAFETY: By the type invariants, this `vm_area_struct` is va= lid and we hold the mmap/vma > > + // read lock or stronger. This implies that the underlying mm = has a non-zero value of > > + // `mm_users`. > > + unsafe { MmWithUser::from_raw((*self.as_ptr()).vm_mm) } > > + } > > + > > + /// Returns the flags associated with the virtual memory area. > > + /// > > + /// The possible flags are a combination of the constants in [`fla= gs`]. > > + #[inline] > > + pub fn flags(&self) -> vm_flags_t { > > + // SAFETY: By the type invariants, the caller holds at least t= he mmap read lock, so this > > + // access is not a data race. > > + unsafe { (*self.as_ptr()).__bindgen_anon_2.vm_flags as _ } > > + } > > + > > + /// Returns the (inclusive) start address of the virtual memory ar= ea. > > + #[inline] > > + pub fn start(&self) -> usize { > > + // SAFETY: By the type invariants, the caller holds at least t= he mmap read lock, so this > > + // access is not a data race. > > + unsafe { (*self.as_ptr()).__bindgen_anon_1.__bindgen_anon_1.vm= _start as _ } > > + } > > + > > + /// Returns the (exclusive) end address of the virtual memory area= . > > + #[inline] > > + pub fn end(&self) -> usize { > > + // SAFETY: By the type invariants, the caller holds at least t= he mmap read lock, so this > > + // access is not a data race. > > + unsafe { (*self.as_ptr()).__bindgen_anon_1.__bindgen_anon_1.vm= _end as _ } > > + } > > + > > + /// Zap pages in the given page range. > > + /// > > + /// This clears page table mappings for the range at the leaf leve= l, leaving all other page > > + /// tables intact, > > I don't fully understand this docstring. Is it correct that the function > will unmap the address range given by `start` and `size`, _and_ free the > pages used to hold the mappings at the leaf level of the page table? If the vma owns a refcount on those pages, then the refcounts are dropped. > > and freeing any memory referenced by the VMA in this range. That is, > > + /// anonymous memory is completely freed, file-backed memory has i= ts reference count on page > > + /// cache folio's dropped, any dirty data will still be written ba= ck to disk as usual. > > + #[inline] > > + pub fn zap_page_range_single(&self, address: usize, size: usize) { > > > Best regards, > Andreas Hindborg > >