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 00684C02183 for ; Wed, 15 Jan 2025 11:04:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 85CA46B0095; Wed, 15 Jan 2025 06:04:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 80D1A6B0096; Wed, 15 Jan 2025 06:04:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6AD256B0098; Wed, 15 Jan 2025 06:04:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 4BCE26B0095 for ; Wed, 15 Jan 2025 06:04:07 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 0BD911411C9 for ; Wed, 15 Jan 2025 11:04:07 +0000 (UTC) X-FDA: 83009401734.18.35295DE Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf17.hostedemail.com (Postfix) with ESMTP id 60C5140013 for ; Wed, 15 Jan 2025 11:04:05 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="G/5SLi4z"; spf=pass (imf17.hostedemail.com: domain of a.hindborg@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=a.hindborg@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736939045; a=rsa-sha256; cv=none; b=t8Ma+0f5q3g+nkoZFPcVod8cBoyfD07AySpty+1OoX5NI8eliKNXHYaRK24ueKM/PX3l/5 nD2BCA1TUWrXp7WlCFsAU3LP/+LERDNKjNVvl+7q/oVmIM7ExJKBDpgvt1Z4h13kNh2sKR fUVtBtdQN0Nl2as3CVTcvxXP7a7FiEE= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="G/5SLi4z"; spf=pass (imf17.hostedemail.com: domain of a.hindborg@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=a.hindborg@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736939045; 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=D/abdDanfxheV3K9MMVeh+CEtpkBxenG9J7HfbhM3DQ=; b=XOWhUyVwZgzFzeMcafnzcRntsTtbke272tZxgtPXHYvXNm9U2pAs7cNPdycEO1+jv09iR1 NjnhCFmAYJlsZtuLdTmaFp5edpqCM+ySifOukAph1eR1M0MdC0WOQ4cb2S5pp9DLZLi47J BUmAxGq6ef8LwikDmHvCpMm7zRmeoxo= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id AD7D5A41D41; Wed, 15 Jan 2025 11:02:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC32AC4CEDF; Wed, 15 Jan 2025 11:03:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736939044; bh=yvllrWEnteI3wxvUxsEtwU29GRVsf9tYU28D6ya1s2Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=G/5SLi4zUtDk82qW5kEd1XbZNtCB3cnoks7gzB4KyAxTLMOq+jz4aZn6leHXk5EEL hArAAEVUuESVZQd7Zih4KLlceL8+M8TjF44J1KQahwISHGZQ7zNLVcHKG0fHLxMPfe pB2tqAiWnT+Yv8Hgvtr0YawZjSxOs9+8JhVMQTsnsddBCLz/BER3nZOZ/cd/a4HYBs A9Nn+yLnPigMQJeGrP5a5EjeaKj8ZyMRX2EuachEsjCsDbrd2rqUJauyqViXhDIXFU VPfZ9DtszuSmQbT3RDSfmdBMEJHjU+98mM8GsXuk+TZA+MUvgR1z03yHvi9ohouLIA 9NhBvmKTEs1ww== From: Andreas Hindborg To: "Alice Ryhl" Cc: "Lorenzo Stoakes" , "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" , =?utf-8?Q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Trevor Gross" , , , Subject: Re: [PATCH v11 1/8] mm: rust: add abstraction for struct mm_struct In-Reply-To: (Alice Ryhl's message of "Mon, 13 Jan 2025 10:53:33 +0100") References: <20241211-vma-v11-0-466640428fc3@google.com> <20241211-vma-v11-1-466640428fc3@google.com> <878qsfdftg.fsf@kernel.org> User-Agent: mu4e 1.12.7; emacs 29.4 Date: Wed, 15 Jan 2025 11:36:56 +0100 Message-ID: <87a5bse52v.fsf@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 60C5140013 X-Stat-Signature: 61yzz4u3cp1yucefwawmwnuxksgia1hs X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1736939045-343002 X-HE-Meta: U2FsdGVkX1/zdNrYfQbTFUkPEUQ9+dnW686j06GejgnsNGmRJRE9DqKCxA6qJH9+FqsgNusL4xQurqv1JXnJXpcUbjWzlBjnqCc4HmUwn/FgL4IlVe/XPPdz9geR8YXBhZE1cfb8YS0MZKgAL7IoJ6JAbj4ZoWutENcpnzgZYn2VVHJTKXfpDMPqNUxoCtdH5rsGDGdPLbNzYpvbEl7Ufo4sP4i9ufuLXWb2ZZCxpQPG/ZQpEeROixTQvyjUthfIoJ+/rLuQjU32FnXy4SSWUTV9GaB7BsvzumLZFMXvYQ6D6tfMQ9MFMrXFdlSusKOyz88Euvt/ruy36ubIoTjQ/h7Jif1Q+KwXQH3BeNvpRGVqpq/NIqzmyR8Mv0h3uOcLn29BphOUGZ2wdG0z2BdRdHNcyNIVclPACLKBB5R2Q3CZdH0zkr/hHP/Vf6JIG0HcOQ3QOm7APnOochGSwBimIPPFjDbwn+Jc2SNHSphxpoUiUhelo6tQu2E7SBUZItGu+PI1zet227iRobIOrOdWea49aS1IeB1dwRhR5pYUI8LSAaSvR9YSvCuH+SQ/axn1zIMZUe4p8DtJEegmUXt8jftXcwXbYPCAX9f4Y+fizOsrb3EJM0M1fJPH1oHH5ClHlb0D1H9/jQrXP5qkihPQqL3mINdcBwxdVdk9AJTdAKY8anpdSMQFq5yR1hvXbuP3FyxSdrDjkPp7+Iu27IS9wgSpHrfMNeeUdk4cKCxTQymh7BnEhHSwsnoytlMxDs3VjMxzdyqa/q7swQ+cDa6M/rumWioQts+1Ru9TCR8v4XdfQQK6b+F9m7R1VjCVtMbtfbye7I197tRd2hqXkVl9I6oT2/l3K/ILtueTCqpBbzBSH7++asOU9a2FSvzGfZ5r+kla6DFgaFgdSEOkCfXNxilgr4VGnXi6r1In6MroOOOwgyjQutNXNnYijtMFdxp0Ek5wBedi24sqy97RCaL h89pspGd AF5v/Bf1dqkntwZBlX8YsMUE68On5kuOYPJ5G2fFMMLn57/o0/HeChjXiseyBgw3ovOWWycZfaKjXtVAjpBmowPqPyTBp7big0d3j0AROi07Wdqj2PBlD+6GhCWyetLDK34krXiJggpNGjpClxe8DDe5Hybs4Vio7Mk4EpALO5vTJwX7mMgg20kQddb2aVSvWJQn+IXCMUvEa6kLLtuTUahwAUXUIeVWA5+kEfzS9yLByPKCdHiZUXboOQw0rT9z51l85NaENn5q6wGK5JtV78oelmOvd0e+9wS1XoNNgPGioZ60CnBgidSrWQLnFtwMi3YjcyvsTTLOFcNWRZZlunv1OC8VJn4e0cRy5ZK9CeUmrvOof8W8AhjjbMDHvVs1A6MGb28eF34Bn27sGd/v3cXahasEdFwozvzjD X-Bogosity: Ham, tests=bogofilter, spamicity=0.196972, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: "Alice Ryhl" writes: > 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 = is >> > 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) Nice =F0=9F=91=8D > >> > +//! >> > +//! 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. Cool =F0=9F=91=8D > >> > +/// >> > +/// Since `mm_users` may be zero, the associated address space may no= t 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 dest= ructor 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. Well I guess there is value in using same names as C. The additional docs you sent help a lot so I guess it is fine. If we were writing from scratch I would have held hard on `AddressSpace` or `MemoryMap` over `Mm`. `Mm` has got to be one of the least descriptive names we can come up with. Best regards, Andreas Hindborg