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 C997EE7719E for ; Mon, 13 Jan 2025 09:53:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38A096B0085; Mon, 13 Jan 2025 04:53:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 339EB6B0088; Mon, 13 Jan 2025 04:53:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 229106B0089; Mon, 13 Jan 2025 04:53:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 053856B0085 for ; Mon, 13 Jan 2025 04:53:48 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 76B54AE308 for ; Mon, 13 Jan 2025 09:53:48 +0000 (UTC) X-FDA: 83001966936.29.3B53A86 Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by imf25.hostedemail.com (Postfix) with ESMTP id 85EA4A000B for ; Mon, 13 Jan 2025 09:53:46 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=lX4xwm9H; spf=pass (imf25.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.49 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=1736762026; 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=HUBuuW0iN8+68G1t2fhNy1Pe5LKA8AnUkEmaZ59Pybs=; b=HhUSgOkkoYqHCvMhS+t0qwMKcRchJcQ1NTvkdGSgo35zQ/ckSJP5JRlvf0QgYA+deOWLuX 4Uacu5wu8u14ueaE8xXZP1OLugeg/asrl5AwQjH6DEqFAN9b59A3683Xp3CFaFvOfulzh0 VyfAJjJtelrTqy/qKoxil6o1FN/D/qE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736762026; a=rsa-sha256; cv=none; b=ZIPWD+FqOV9apDt3Mr/r/8mH4e+3SFDcGnQrb817xJXhl26wv8F8QYfbqshx/0dVypg+gK /WIN1y6joUlrbMD/bb+dBw9Nmo1NqWTPGKQ7ixGE03/URmeFBr8/l3PIuLmup/i2LAcUR3 HTDWQ6nUGPe/Pn2vNYHMDHyAKJ79Wns= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=lX4xwm9H; spf=pass (imf25.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.49 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-38632b8ae71so2945659f8f.0 for ; Mon, 13 Jan 2025 01:53:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736762025; x=1737366825; 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=HUBuuW0iN8+68G1t2fhNy1Pe5LKA8AnUkEmaZ59Pybs=; b=lX4xwm9HgcTSVFgH7t21OTWA1Dneh84pkosfCyVBmb0wFUnG0j6VUoEp9szK2WtRQx 50jWagV1XuA0NGxGporghtnhwlTuzooQMiiffMGEMiUO4hPr+dDvuVO3McerySRNs5hX LPewYH5m+fQ7Gfhm4p44H1reGFol/lZJTRLF2mfcSU7kvIrsILigXamOhRxAZ+k1Z6am mFO4J41gwy63IT2dcvT9rb0TCuOvC/dI1JXsQsT22U+vyD69DLiZi7bYTROfnplTldlB QChtVWguQU4yxeabGi4kTewCFXjlIZxwbRP4vBmRAZD2CcV1q5z9SeSK1GO+k4+gujtN YSdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736762025; x=1737366825; 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=HUBuuW0iN8+68G1t2fhNy1Pe5LKA8AnUkEmaZ59Pybs=; b=MZSA6ZBASrZUSEvnq84Ulrowt0G2dc1MV+9BOiCnhIIZzrRQ34T1TdqQrVKu/wVZU0 J14D1IoPdLZQNuBeWKSao3SZphBFo/KUlIGIN/hfHB11f6IJYz7oJ7qp1NkAq5G9B+VU H/jcdjq8haZOibbgq33y96OQ+8IzFlgSmWmgue0FGBL+fzkkgOlE6isa332GQvJd/P9W NzLWhAf31pm8rdn2P1OzFydiPzbwm2L/XW+plss9xO6zszNjEZG04sxiGxdV6bOiEwzG eKkEhQFWbfhxqXLd7g56sSylfz2dnKEsfoQE/W1SYa1gIp4AqVR9aCP84ufsjihX9llF NmFA== X-Forwarded-Encrypted: i=1; AJvYcCXBEnvNASU0ziewsSpephgbKBESMtO1u5deaqXwqS8W52JOhz8YNvOrMfrON4VIssaCUDJlprHcVQ==@kvack.org X-Gm-Message-State: AOJu0YxYbQANZD5hDeEOUZCWDyGGHxDAq45tuqRXOOyQTClBo29e6hlF FckQgxJDEoQwFSFkSQj3fu2qCR7gjLhlp+V1akcOIKT7er1IXzWqflJx/ST/CgQ0HkYv5Q4TKYK pQuFWqbIATbSdBmK19RVvRZw1mhFn0gxz4Xmu X-Gm-Gg: ASbGncvKhQXTAYKEGw9mhF8xfdix1n5Vd502eHoiwhuIV2RhSfmpiYr7sHkcvywLreK owMDDXsZLvBSWnXA/YTV4Ci2Ut41dZS3T9YA5H8G6TPzaTG7TC4yhSZF17y/nFNTgPzXL X-Google-Smtp-Source: AGHT+IEQqMabAkD1+qyAoHLAVyPwUyYMSvNjSOuAZSZQySc785S9sxkR7vreXAsH6CGRA3/89aZiuj6FuSw0G3T1gEY= X-Received: by 2002:a05:6000:1445:b0:385:df6d:6fc7 with SMTP id ffacd0b85a97d-38a8730ce5amr19322756f8f.25.1736762024963; Mon, 13 Jan 2025 01:53:44 -0800 (PST) MIME-Version: 1.0 References: <20241211-vma-v11-0-466640428fc3@google.com> <20241211-vma-v11-1-466640428fc3@google.com> <878qsfdftg.fsf@kernel.org> In-Reply-To: <878qsfdftg.fsf@kernel.org> From: Alice Ryhl Date: Mon, 13 Jan 2025 10:53:33 +0100 X-Gm-Features: AbW1kvYo1SEI0t_S31-KQLibOnyOcXxKtrqq6xo8-o7-XZyUD1sjn3nZMe3yW3M Message-ID: Subject: Re: [PATCH v11 1/8] mm: rust: add abstraction for struct mm_struct To: Andreas Hindborg , Lorenzo Stoakes Cc: Miguel Ojeda , Matthew Wilcox , 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=3Fus-ascii=3FQ=3F=3D3D?= =?us-ascii?Q?=3D3Futf-8=3D3FQ=3D3FBj=3D3DC3=3F=3D_=3D=3Fus-ascii=3FQ=3F?= =?us-ascii?Q?=3D3DB6rn=3D3F=3D3D=3F=3D?= 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: 85EA4A000B X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: rt7ayp9ka5j8ws7yom5cdkgtxxd5fuku X-HE-Tag: 1736762026-538614 X-HE-Meta: U2FsdGVkX192kw/0EtMZYr4+As//fTwKR5bHuwCMMcSFrIMcBs7h7QGgfsaNzVHKG2mbqcfM4AmIlCRQCt9oYx+ZRBA2yjhZuqK8pSermyHviYddblrZrvHZ+s0f+GiwCHroAGf8z98hz/Jp8q8JLU7zNwtKgMnTwat9JyaTv9SmIHUvsKsdEvvjTNfZ8Lr3cmTLU7bgz/N1iQHQsNFxVajN7GAAk5KuZlkg5lSDKZ6kyQdnyVpZbi4x6UjMXzVNswg6I5bq6y1zSoWGPxpp8GuKO3SQWfUuZ8K+Q64g5y+x9hugsntOI+23YeWWRL8hcInONAgZrLBJoIQLp8vDk1lsnzY6zk6Z9K9B0CVGJxkNykf+lnaZZ/YS+v/vAz0wk5ScAovctwS2pcO/N/JAtgdo0bbRG1EvfVi6in9rHs9fCw2NCNOjefFlYVSRQQ6pUP6QfC6eJ1NwucxzPeaSebfoXIQ2AQeZ8GKrGXnqTWk4DgEFGrX31XSlElahf3aEbild2Im+JXvAQ+e98WDrr1NT0j7/bxQ1WabPxBw7IrQl+SLv/cvKo6Eu7FKYG9Vd3QDfxhbXr508dsKc9yo+I82tZSPN2pkMleyqmKNM5uyw6poR/uWpoC6KH4dNodZbzWvmBfDSB0bap6+dt3/Flf0QzKDgHWy5r+rg4pCLsH1/ij3Yxy6ZTbeei8+h9mr3oRD1SScbD8fID+2AsWiFTo0SNNi6IwAKvbgQ/GNp9LeI4gwP1ijRJcL21JLyuHMxpx0Y2cheo69G/B7y9QVE2XZNQGurvXJXMX4yibtul+mbbQ6CdJjpTmM70KIVtoS9X2+w4zPmOK56TubIvic0bTh0qpe9bpDcIwXqqHGFEZolfpdV64rzq2CumWO69MP7qNgPa6nH+FKgdmdY9fEU155Ife4kvtQhnIQf88eFmIuONa3U9FHlPd2TVCObSinyqaauoRBXQHvm/zKo5bO kuj2w8wz Ya9n2nu5optXbSL5qjHPK0bqWW2kZ1oZCsyiASMt1dbABcsZ9w2PgKXRa2kPRLOyzamwX2tmUD8NGfkYk/0atNfuHBlKqA7PRJGxQcfBIxnvY4lBdPXFwRp7k4RxDTpWAXh5OpW7JsUBEYQumybUphPQMkG4tC3cXY4PaAx6npFsqX/ysH94b4U8fT8Op+zLdKN3nr7gOvUtE1oawv1lUO66W+nlV5VU95x8ByDDGOm7DDBFU4/1WDIhQzaEtbz4VMPSzG65vWkmlNsbivSIJDdsA0BiGFtJFeAOHbjneKkzDnYu4vD40EElAMLXYQqzPaQ0UdJiU9XfY1HGf5lbc0n9yOSBmRF3lvb0RxJJZuwSgAXZNErZgi2XpSFYRXBn56tCHLb5JFkY60moor5oFhAGNb73oloimaNSX X-Bogosity: Ham, tests=bogofilter, spamicity=0.371501, 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: > > > These abstractions allow you to reference a `struct mm_struct` using > > both mmgrab and mmget refcounts. This is done using two Rust types: > > > > * Mm - represents an mm_struct where you don't know anything about the > > value of mm_users. > > * MmWithUser - represents an mm_struct where you know at compile time > > that mm_users is non-zero. > > > > This allows us to encode in the type system whether a method requires > > that mm_users is non-zero or not. For instance, you can always call > > `mmget_not_zero` but you can only call `mmap_read_lock` when mm_users i= s > > non-zero. > > > > It's possible to access current->mm without a refcount increment, but > > that is added in a later patch of this series. > > > > Acked-by: Lorenzo Stoakes (for mm bits) > > Signed-off-by: Alice Ryhl > > --- > > rust/helpers/helpers.c | 1 + > > rust/helpers/mm.c | 39 +++++++++ > > rust/kernel/lib.rs | 1 + > > rust/kernel/mm.rs | 219 +++++++++++++++++++++++++++++++++++++++++= ++++++++ > > 4 files changed, 260 insertions(+) > > > > diff --git a/rust/kernel/mm.rs b/rust/kernel/mm.rs > > new file mode 100644 > > index 000000000000..84cba581edaa > > --- /dev/null > > +++ b/rust/kernel/mm.rs > > @@ -0,0 +1,219 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > + > > +// Copyright (C) 2024 Google LLC. > > + > > +//! Memory management. > > Could you add a little more context here? How about this? //! Memory management. //! //! This module deals with managing the address space of userspace processes. Each process has an //! instance of [`Mm`], which keeps track of multiple VMAs (virtual memory areas). Each VMA //! corresponds to a region of memory that the userspace process can access, and the VMA lets you //! control what happens when userspace reads or writes to that region of memory. //! //! C header: [`include/linux/mm.h`](srctree/include/linux/mm.h) > > +//! > > +//! C header: [`include/linux/mm.h`](srctree/include/linux/mm.h) > > + > > +use crate::{ > > + bindings, > > + types::{ARef, AlwaysRefCounted, NotThreadSafe, Opaque}, > > +}; > > +use core::{ops::Deref, ptr::NonNull}; > > + > > +/// A wrapper for the kernel's `struct mm_struct`. > > Could you elaborate the data structure use case? When do I need it, what > does it do? How about this? /// A wrapper for the kernel's `struct mm_struct`. /// /// This represents the address space of a userspace process, so each process has one `Mm` /// instance. It may hold many VMAs internally. /// /// There is a counter called `mm_users` that counts the users of the address space; this includes /// the userspace process itself, but can also include kernel threads accessing the address space. /// Once `mm_users` reaches zero, this indicates that the address space can be destroyed. To access /// the address space, you must prevent `mm_users` from reaching zero while you are accessing it. /// The [`MmWithUser`] type represents an address space where this is guaranteed, and you can /// create one using [`mmget_not_zero`]. /// /// The `ARef` smart pointer holds an `mmgrab` refcount. Its destructor may sleep. > > +/// > > +/// Since `mm_users` may be zero, the associated address space may not= exist anymore. You can use > > +/// [`mmget_not_zero`] to be able to access the address space. > > +/// > > +/// The `ARef` smart pointer holds an `mmgrab` refcount. Its destr= uctor may sleep. > > +/// > > +/// # Invariants > > +/// > > +/// Values of this type are always refcounted using `mmgrab`. > > +/// > > +/// [`mmget_not_zero`]: Mm::mmget_not_zero > > +#[repr(transparent)] > > +pub struct Mm { > > Could we come up with a better name? `MemoryMap` or `MemoryMapping`?. You > use `MMapReadGuard` later. Those names seem really confusing to me. The mmap syscall creates a new VMA, but MemoryMap sounds like it's the thing that mmap creates. Lorenzo, what do you think? I'm inclined to just call it Mm since that's what C calls it. Alice