From: Andreas Hindborg <a.hindborg@kernel.org>
To: "Alice Ryhl" <aliceryhl@google.com>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
"Matthew Wilcox" <willy@infradead.org>,
"Lorenzo Stoakes" <lorenzo.stoakes@oracle.com>,
"Vlastimil Babka" <vbabka@suse.cz>,
"John Hubbard" <jhubbard@nvidia.com>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arnd Bergmann" <arnd@arndb.de>,
"Christian Brauner" <brauner@kernel.org>,
"Jann Horn" <jannh@google.com>,
"Suren Baghdasaryan" <surenb@google.com>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
=?us-ascii?Q?=3D=3Fus-ascii=3FQ=3F=3D3D?=
=?us-ascii?Q?=3D3Fus-ascii=3D3FQ=3D3F=3D3D3D=3F=3D_=3D=3Fus-ascii=3FQ=3F?=
=?us-ascii?Q?=3D3D3Futf-8=3D3D3FQ=3D3D3FBj=3D3D3DC3=3D3F=3D3D=5F=3D3D=3D3?=
=?us-ascii?Q?Fus-ascii=3D3FQ=3D3F=3F=3D_=3D=3Fus-ascii=3FQ=3F=3D3D3DB6rn?=
=?us-ascii?Q?=3D3D3F=3D3D3D=3D3F=3D3D=3F=3D?= Roy Baron
<bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Trevor Gross" <tmgross@umich.edu>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v11 1/8] mm: rust: add abstraction for struct mm_struct
Date: Mon, 16 Dec 2024 12:31:55 +0100 [thread overview]
Message-ID: <878qsfdftg.fsf@kernel.org> (raw)
In-Reply-To: <20241211-vma-v11-1-466640428fc3@google.com> (Alice Ryhl's message of "Wed, 11 Dec 2024 10:37:05 +0000")
"Alice Ryhl" <aliceryhl@google.com> 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 <lorenzo.stoakes@oracle.com> (for mm bits)
> Signed-off-by: Alice Ryhl <aliceryhl@google.com>
> ---
> 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?
> +//!
> +//! 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?
> +///
> +/// 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<Mm>` smart pointer holds an `mmgrab` refcount. Its destructor 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.
> + mm: Opaque<bindings::mm_struct>,
> +}
> +
> +// SAFETY: It is safe to call `mmdrop` on another thread than where `mmgrab` was called.
> +unsafe impl Send for Mm {}
> +// SAFETY: All methods on `Mm` can be called in parallel from several threads.
> +unsafe impl Sync for Mm {}
> +
> +// SAFETY: By the type invariants, this type is always refcounted.
> +unsafe impl AlwaysRefCounted for Mm {
> + #[inline]
> + fn inc_ref(&self) {
> + // SAFETY: The pointer is valid since self is a reference.
> + unsafe { bindings::mmgrab(self.as_raw()) };
> + }
> +
> + #[inline]
> + unsafe fn dec_ref(obj: NonNull<Self>) {
> + // SAFETY: The caller is giving up their refcount.
> + unsafe { bindings::mmdrop(obj.cast().as_ptr()) };
> + }
> +}
> +
> +/// A wrapper for the kernel's `struct mm_struct`.
> +///
> +/// This type is like [`Mm`], but with non-zero `mm_users`. It can only be used when `mm_users` can
> +/// be proven to be non-zero at compile-time, usually because the relevant code holds an `mmget`
> +/// refcount. It can be used to access the associated address space.
> +///
> +/// The `ARef<MmWithUser>` smart pointer holds an `mmget` refcount. Its destructor may sleep.
> +///
> +/// # Invariants
> +///
> +/// Values of this type are always refcounted using `mmget`. The value of `mm_users` is non-zero.
> +#[repr(transparent)]
> +pub struct MmWithUser {
> + mm: Mm,
> +}
> +
> +// SAFETY: It is safe to call `mmput` on another thread than where `mmget` was called.
> +unsafe impl Send for MmWithUser {}
> +// SAFETY: All methods on `MmWithUser` can be called in parallel from several threads.
> +unsafe impl Sync for MmWithUser {}
> +
> +// SAFETY: By the type invariants, this type is always refcounted.
> +unsafe impl AlwaysRefCounted for MmWithUser {
> + #[inline]
> + fn inc_ref(&self) {
> + // SAFETY: The pointer is valid since self is a reference.
> + unsafe { bindings::mmget(self.as_raw()) };
> + }
> +
> + #[inline]
> + unsafe fn dec_ref(obj: NonNull<Self>) {
> + // SAFETY: The caller is giving up their refcount.
> + unsafe { bindings::mmput(obj.cast().as_ptr()) };
> + }
> +}
> +
> +// Make all `Mm` methods available on `MmWithUser`.
> +impl Deref for MmWithUser {
> + type Target = Mm;
> +
> + #[inline]
> + fn deref(&self) -> &Mm {
> + &self.mm
> + }
> +}
> +
> +// These methods are safe to call even if `mm_users` is zero.
> +impl Mm {
> + /// Call `mmgrab` on `current.mm`.
> + #[inline]
> + pub fn mmgrab_current() -> Option<ARef<Mm>> {
> + // SAFETY: It's safe to get the `mm` field from current.
> + let mm = unsafe {
> + let current = bindings::get_current();
> + (*current).mm
> + };
> +
> + if mm.is_null() {
> + return None;
> + }
> +
> + // SAFETY: The value of `current->mm` is guaranteed to be null or a valid `mm_struct`. We
> + // just checked that it's not null. Furthermore, the returned `&Mm` is valid only for the
> + // duration of this function, and `current->mm` will stay valid for that long.
> + let mm = unsafe { Mm::from_raw(mm) };
> +
> + // This increments the refcount using `mmgrab`.
> + Some(ARef::from(mm))
> + }
> +
> + /// Returns a raw pointer to the inner `mm_struct`.
> + #[inline]
> + pub fn as_raw(&self) -> *mut bindings::mm_struct {
> + self.mm.get()
> + }
> +
> + /// Obtain a reference from a raw pointer.
> + ///
> + /// # Safety
> + ///
> + /// The caller must ensure that `ptr` points at an `mm_struct`, and that it is not deallocated
> + /// during the lifetime 'a.
> + #[inline]
> + pub unsafe fn from_raw<'a>(ptr: *const bindings::mm_struct) -> &'a Mm {
> + // SAFETY: Caller promises that the pointer is valid for 'a. Layouts are compatible due to
> + // repr(transparent).
> + unsafe { &*ptr.cast() }
> + }
> +
> + /// Calls `mmget_not_zero` and returns a handle if it succeeds.
> + #[inline]
> + pub fn mmget_not_zero(&self) -> Option<ARef<MmWithUser>> {
> + // SAFETY: The pointer is valid since self is a reference.
> + let success = unsafe { bindings::mmget_not_zero(self.as_raw()) };
> +
> + if success {
> + // SAFETY: We just created an `mmget` refcount.
> + Some(unsafe { ARef::from_raw(NonNull::new_unchecked(self.as_raw().cast())) })
> + } else {
> + None
> + }
> + }
> +}
Nit: could we put the impl next to the struct definition?
Best regards,
Andreas Hindborg
next prev parent reply other threads:[~2024-12-16 14:50 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <nGnC07PmUqofHiX7HfZAOCIK1-CPS7DF8kdGhDgJgPts5KYrCrimmovP-4YMVgI7WRmFnGwbdndTtxCfp278cg==@protonmail.internalid>
2024-12-11 10:37 ` [PATCH v11 0/8] Rust support for mm_struct, vm_area_struct, and mmap Alice Ryhl
2024-12-11 10:37 ` [PATCH v11 1/8] mm: rust: add abstraction for struct mm_struct Alice Ryhl
2024-12-16 11:31 ` Andreas Hindborg [this message]
2025-01-13 9:53 ` Alice Ryhl
2025-01-14 15:48 ` Lorenzo Stoakes
2025-01-15 1:54 ` John Hubbard
2025-01-15 12:13 ` Lorenzo Stoakes
2025-01-15 10:36 ` Andreas Hindborg
2025-01-15 20:20 ` John Hubbard
2025-01-17 0:45 ` Balbir Singh
2025-01-17 12:47 ` Alice Ryhl
2024-12-11 10:37 ` [PATCH v11 2/8] mm: rust: add vm_area_struct methods that require read access Alice Ryhl
2024-12-16 12:12 ` Andreas Hindborg
2025-01-08 12:21 ` Alice Ryhl
2025-01-09 8:02 ` Andreas Hindborg
2025-01-09 8:19 ` Lorenzo Stoakes
2025-01-09 9:50 ` Andreas Hindborg
2025-01-09 11:29 ` Lorenzo Stoakes
2025-01-09 15:32 ` Andreas Hindborg
2025-01-13 14:45 ` Lorenzo Stoakes
2025-01-14 9:50 ` Alice Ryhl
2025-01-14 11:57 ` Lorenzo Stoakes
2025-01-14 13:42 ` Alice Ryhl
2025-01-14 15:33 ` Lorenzo Stoakes
2025-01-15 11:02 ` Andreas Hindborg
2025-01-15 11:04 ` Alice Ryhl
2024-12-11 10:37 ` [PATCH v11 3/8] mm: rust: add vm_insert_page Alice Ryhl
2024-12-16 12:25 ` Andreas Hindborg
2025-01-13 10:02 ` Alice Ryhl
2025-01-15 9:33 ` Andreas Hindborg
2024-12-11 10:37 ` [PATCH v11 4/8] mm: rust: add lock_vma_under_rcu Alice Ryhl
2024-12-16 12:47 ` Andreas Hindborg
2025-01-13 10:04 ` Alice Ryhl
2025-01-15 9:34 ` Andreas Hindborg
2024-12-11 10:37 ` [PATCH v11 5/8] mm: rust: add mmput_async support Alice Ryhl
2024-12-16 13:10 ` Andreas Hindborg
2024-12-11 10:37 ` [PATCH v11 6/8] mm: rust: add VmAreaNew for f_ops->mmap() Alice Ryhl
2024-12-16 13:41 ` Andreas Hindborg
2025-01-08 12:23 ` Alice Ryhl
2025-01-09 8:19 ` Andreas Hindborg
2025-01-13 10:17 ` Alice Ryhl
2025-01-15 9:57 ` Andreas Hindborg
2024-12-17 9:31 ` Andreas Hindborg
2025-01-08 12:24 ` Alice Ryhl
2025-01-09 8:23 ` Andreas Hindborg
2025-01-13 10:18 ` Alice Ryhl
2025-01-10 13:34 ` Alice Ryhl
2025-01-10 16:09 ` Lorenzo Stoakes
2024-12-11 10:37 ` [PATCH v11 7/8] rust: miscdevice: add mmap support Alice Ryhl
2024-12-16 13:53 ` Andreas Hindborg
2024-12-11 10:37 ` [PATCH v11 8/8] task: rust: rework how current is accessed Alice Ryhl
2024-12-16 14:47 ` Andreas Hindborg
2025-01-08 12:32 ` Alice Ryhl
2025-01-09 8:42 ` Andreas Hindborg
2025-01-13 10:26 ` Alice Ryhl
2025-01-15 10:24 ` Andreas Hindborg
2024-12-16 23:40 ` Boqun Feng
2025-01-13 10:30 ` Alice Ryhl
2025-01-14 15:30 ` Boqun Feng
2024-12-11 10:47 ` [PATCH v11 0/8] Rust support for mm_struct, vm_area_struct, and mmap Alice Ryhl
2024-12-12 14:47 ` Konstantin Ryabitsev
2024-12-13 14:42 ` Alice Ryhl
2024-12-13 14:47 ` Konstantin Ryabitsev
2024-12-16 11:04 ` Andreas Hindborg
2024-12-16 11:46 ` Alice Ryhl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878qsfdftg.fsf@kernel.org \
--to=a.hindborg@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=arnd@arndb.de \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=brauner@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=jannh@google.com \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=surenb@google.com \
--cc=tmgross@umich.edu \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.