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 47B98C021B2 for ; Tue, 25 Feb 2025 16:25:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D0E8E280008; Tue, 25 Feb 2025 11:25:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CF028280003; Tue, 25 Feb 2025 11:25:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B5F9D280008; Tue, 25 Feb 2025 11:25:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 94E56280003 for ; Tue, 25 Feb 2025 11:25:27 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 09604120FD8 for ; Tue, 25 Feb 2025 16:25:27 +0000 (UTC) X-FDA: 83158992294.12.2E39C1B Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by imf30.hostedemail.com (Postfix) with ESMTP id 0E3F18000C for ; Tue, 25 Feb 2025 16:25:24 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RrTHsztY; spf=pass (imf30.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.43 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=1740500725; 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=cLxFWJr5SBm2uwG1aose8lFaFsHP1M9jCT6EPEpJIsU=; b=hjEASAave8B66byidL8A8sdkkbfgr2DLthUR7H3AUgT9DdOhTS9F3Mirdzp+FJ071WP53t b61wAfoGvIlVKEb+2upPi7Cg9KWFT4VdYDSgk7y4sOlsjGQFzVoCKSulyL6sxdtUGNcIQA Lf8vCTam57J0GAZ0tyNlTXcOg4BJmlI= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RrTHsztY; spf=pass (imf30.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.43 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740500725; a=rsa-sha256; cv=none; b=xynjIqxAN6himjNqtJE0qmTwnL+Zsj7k6sdeDkjOQZ2RsWWbkvY8EbJiBeD1GM8ISsfv88 N6NDqChAdoIf60pC9f5tePH+6wx6yuIrVo5fQqAVvJncPqgGF49BK/T3Y8fW5QfA6QWt/q 0NoatbPZ1Zn5QhGobnmF+A94o9DWORQ= Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-38f31f7731fso2837237f8f.0 for ; Tue, 25 Feb 2025 08:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740500723; x=1741105523; 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=cLxFWJr5SBm2uwG1aose8lFaFsHP1M9jCT6EPEpJIsU=; b=RrTHsztY8w94YEykBeRRuWyEL2P3jwBOMdXTLFx/AgOsonIzPkndWagGPROOKJj6cp ht8PiXXbzW4gK1OoudM8XqRSknlI6Z845Rc7e57NRn2nLAk4urn5WyfZmiSlBdTcysmG UUqOs0Q23zd5ru2p3zL1z+lvC38Jnlq/SM3Xg1mlL8d91HJ+IQbA7lyrjCS1VubrYkyT QmMaAPQvPG1SvClZfmRavELXZ3uaKPrVLycUDaWRxg7owH0dPBs3C7fCrbSjMqdHrwaa fKc5N+9Tsq8crsFS3NneZLkAc/8ZAZ8PP7bYvCR8mGxvuAnOv3Q4sY0Tc3acTKnk5u8d ZPNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740500723; x=1741105523; 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=cLxFWJr5SBm2uwG1aose8lFaFsHP1M9jCT6EPEpJIsU=; b=l7yfn2TcoPUMpLXDC6+0tlVCJx//9TxwxU0N0N7b8SE1uBiNe2XhFjdTh6gBSbmxuF krX/FSNPsSLNuwyVUuyH+OAp1/whwCWfxPvE/FHthf+jj5QZo5Ev7PARLAOXz4PIC9Gb CntKArt2HCxCehN31oHh8Eg2WS3BTClIDQu7/hKuqXm/mixst7qEUYMITz2q0AtjR5ug xZQbL6NaS7r7RoKpP2s0sAlHFMX8sSWNSTqKG0NqGUJX2Vuy8R9iA+2C2H57cqNjKty6 uZS2vxLMa5/8FbpXiltqP5UduNa59IbpVgcNw679kRQgdn9NIbpCJUPTE7RNfdM2jVv9 xJ9Q== X-Forwarded-Encrypted: i=1; AJvYcCXmR8QVY6mUKQSruxGKjtOdDZtn47G6Sb5bX87vkymdq/Kw4qKhEQaz8tEWdYCUqw7oZed6XbbZdg==@kvack.org X-Gm-Message-State: AOJu0YzMfs7RyoPlY0QTrqQbVnMztbXHlRBRN2NVkCsw9E9NP9R+QmS6 IdUzExtQzePFMB9wlggKgfnDKCakkCYAuT3T61oLSvdCrIWTBgTF2sNvTlTzln0+brDStNIX7pv mosJzoHLv8AJ4ZY0g9T6pKlQFPnlGK3Rt6jYn X-Gm-Gg: ASbGncuGWhb5OyRGrOtwobmGZ5SCNubHsJbC9kojmdRjaZFZDT7cz8zSy9xp1zrvrM4 UlY7JG8nf23e0g/GQNn6ZA+KJrriOsU05/uOCAfMMHtomsmkZ0BnjoorRuWHog3ZiATl1zfU1sX 4Nwgsewacb6IA2kudAN0I9XWYzC8tpGeiSWvU95Q== X-Google-Smtp-Source: AGHT+IEL/VAlIzC/72gt6UlPgqwmOgVfnvRRlHIzH2wOPjqxna9GiiQv4vbpSwWWRe3ewdVZoSIlBFaXfkrlmy6v6H0= X-Received: by 2002:a05:6000:154a:b0:38f:4251:5971 with SMTP id ffacd0b85a97d-38f6e753b0bmr14003071f8f.6.1740500723345; Tue, 25 Feb 2025 08:25:23 -0800 (PST) MIME-Version: 1.0 References: <20250213-vma-v14-0-b29c47ab21f5@google.com> <20250213-vma-v14-6-b29c47ab21f5@google.com> <20250225162400.37187f22@eugeo> In-Reply-To: <20250225162400.37187f22@eugeo> From: Alice Ryhl Date: Tue, 25 Feb 2025 17:25:11 +0100 X-Gm-Features: AQ5f1JoEC3x9WNKgVd-On0faB1EZd0DxKFqSTrzCe8bV0fCShAQBPXTzoaNz4yc Message-ID: Subject: Re: [PATCH v14 6/8] mm: rust: add VmaNew for f_ops->mmap() To: Gary Guo Cc: Miguel Ojeda , Matthew Wilcox , Lorenzo Stoakes , Vlastimil Babka , John Hubbard , "Liam R. Howlett" , Andrew Morton , Greg Kroah-Hartman , Arnd Bergmann , Jann Horn , Suren Baghdasaryan , Alex Gaynor , Boqun Feng , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , 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: 0E3F18000C X-Stat-Signature: ruimidaq4ok7p9x46z49r7nx84hbxoet X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1740500724-81440 X-HE-Meta: U2FsdGVkX19+y+KEHELnp2iQmEM8DAU4z9FmplREHX82wlma4jP5+T5jzAzM3V8jms+yrB8sDto+YM+A42nhmgvjlL4C58BLxAbPNjsvWZhMxy5AP7XYOBf7iiaCIkLgyQwIuuDW+zomOSnF48sLDjgPaWpPCxQpYK7KBkg/TjgPiDcNhVqSfaxF83KHcW9sqa2YOi26rqtwMPcV6cmlLk7VFkUAREbDUjgk5aHrBuFX0OLe9SeU9CG9k/N7Bz1lqNFhV4L3Yge17BBeiA1WQ/jfw8FtejupB6+9m/cr1mmE0RjVy2zGngT/EyIvsHVSDzU1Bz1fsLK+a5cn1TvaP9sUpqytdS661jq1h+l1ZPoRYpN0XlmlYnvJDGSMNl0AHWQYF3xssvj2drKFQZKoEk11bWHMby7ITKfxjJxwwTySxtEW2MPVHZaBbpc9qkXTYgk9d/6ExGhPRq/CfNq78203Mhigk0wFNpPKmz6uW9D0cuikkQQHEEDOO6pihOs/LBcJTojj0pt2tPhCc/MtOmZKWH5tQFrbQZyjrLidBrro36fhYHvDi57W720/u+lrCRQ0y5Kc/+2pW0vc/VJGugW8nvdha32YB29Glj5E1L+cxoNUMfs/Mx2xUu2OQ7706P/5oJ313g3tdd3UT585UB9YdG2okqc+HGZhmH1U3OVJTflaUuh77AHMQBCbzPtsHldpEEx5TzyQ0XDBeGEtiSvBIhGlfdCvXWaTfxD9PIK1BxLdN4nlrgJX3LZtL1AwV7N9f3pZoK4N4n9HQNJwr6xgPRcEEvt6mq+z3upjd5T0BKx2J3IFF8Na1b+7IJVVou+6UfaVH5Cqm+A+EJYPosK6jtGX0OqedLssOXWmRhMY1Q0q3xsOVaKilOYouyAFgHG9HaQGXQ5GHPS3qs+4nqzXpcpHGdwRbVQKg4wIXG0IsUzxV3zBSbsKdx2YKcuNJ9TVC/5kP+SYiuT2cWz tuTHI5Bp C4Qsvt01Q7zAyU6XT53+p5nTTKZ79V8y/qVtmTtltWcokI2BucgHpEfq+5XpT1h0Z92vGS3J2mbkHzm4Kv18QLdASCscBTHk3UdsXLHQe9PRq3WSkm+qU8JbGMvnAclwvzyzC7qI4J2ByT0WSXp4h7/+v2XA5NCLC/jk4R5ROsLM/w6h6uFkeCOp+FmaocqVLefXEr5stug5Ugjf2qweowDh0NMSQiYVN0JXBTT3AiOjMQA5AGGxfZLpcEkbTxHGXnsAveFO+OKzPIpdrgMLzQCdP22cowbg9u7TjABJAUP1ncUUv6G6iuNAlF8n7QF9fPYLNerG/H+hlq6O8aHLZq83ZQsf0WnR6LY2Ok9nMdfBmLgUsYOFDp8mLKOpDVwu6H8Y5fESa5m8+LEq+j26eIgGLXJrEqFSVpUuvUsQi90upQf4tvZDauX9adQGnvkAZmo3h X-Bogosity: Ham, tests=bogofilter, spamicity=0.415757, 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 Tue, Feb 25, 2025 at 5:24=E2=80=AFPM Gary Guo wrote: > > On Thu, 13 Feb 2025 11:04:05 +0000 > Alice Ryhl wrote: > > > This type will be used when setting up a new vma in an f_ops->mmap() > > hook. Using a separate type from VmaRef allows us to have a separate se= t > > of operations that you are only able to use during the mmap() hook. For > > example, the VM_MIXEDMAP flag must not be changed after the initial > > setup that happens during the f_ops->mmap() hook. > > > > To avoid setting invalid flag values, the methods for clearing > > VM_MAYWRITE and similar involve a check of VM_WRITE, and return an erro= r > > if VM_WRITE is set. Trying to use `try_clear_maywrite` without checking > > the return value results in a compilation error because the `Result` > > type is marked #[must_use]. > > > > For now, there's only a method for VM_MIXEDMAP and not VM_PFNMAP. When > > we add a VM_PFNMAP method, we will need some way to prevent you from > > setting both VM_MIXEDMAP and VM_PFNMAP on the same vma. > > > > Acked-by: Lorenzo Stoakes > > Reviewed-by: Jann Horn > > Reviewed-by: Andreas Hindborg > > Signed-off-by: Alice Ryhl > > --- > > rust/kernel/mm/virt.rs | 186 +++++++++++++++++++++++++++++++++++++++++= +++++++- > > 1 file changed, 185 insertions(+), 1 deletion(-) > > > > diff --git a/rust/kernel/mm/virt.rs b/rust/kernel/mm/virt.rs > > index 3e2eabcc2145..31803674aecc 100644 > > --- a/rust/kernel/mm/virt.rs > > +++ b/rust/kernel/mm/virt.rs > > @@ -16,7 +16,7 @@ > > > > use crate::{ > > bindings, > > - error::{to_result, Result}, > > + error::{code::EINVAL, to_result, Result}, > > mm::MmWithUser, > > page::Page, > > types::Opaque, > > @@ -198,6 +198,190 @@ pub fn vm_insert_page(&self, address: usize, page= : &Page) -> Result { > > } > > } > > > > +/// A configuration object for setting up a VMA in an `f_ops->mmap()` = hook. > > +/// > > +/// The `f_ops->mmap()` hook is called when a new VMA is being created= , and the hook is able to > > +/// configure the VMA in various ways to fit the driver that owns it. = Using `VmaNew` indicates that > > +/// you are allowed to perform operations on the VMA that can only be = performed before the VMA is > > +/// fully initialized. > > +/// > > +/// # Invariants > > +/// > > +/// For the duration of 'a, the referenced vma must be undergoing init= ialization in an > > +/// `f_ops->mmap()` hook. > > +pub struct VmaNew { > > + vma: VmaRef, > > +} > > + > > +// Make all `VmaRef` methods available on `VmaNew`. > > Are there operations that can't be performed when VMA is still being > setup? If so, using typestate might be more preferrable to Deref. I don't think so. > > +impl Deref for VmaNew { > > + type Target =3D VmaRef; > > + > > + #[inline] > > + fn deref(&self) -> &VmaRef { > > + &self.vma > > + } > > +} > > + > > +impl VmaNew { > > + /// Access a virtual memory area given a raw pointer. > > + /// > > + /// # Safety > > + /// > > + /// Callers must ensure that `vma` is undergoing initial vma setup= for the duration of 'a. > > + #[inline] > > + pub unsafe fn from_raw<'a>(vma: *mut bindings::vm_area_struct) -> = &'a Self { > > + // SAFETY: The caller ensures that the invariants are satisfie= d for the duration of 'a. > > + unsafe { &*vma.cast() } > > + } > > + > > + /// Internal method for updating the vma flags. > > + /// > > + /// # Safety > > + /// > > + /// This must not be used to set the flags to an invalid value. > > + #[inline] > > + unsafe fn update_flags(&self, set: vm_flags_t, unset: vm_flags_t) = { > > + let mut flags =3D self.flags(); > > + flags |=3D set; > > + flags &=3D !unset; > > + > > + // SAFETY: This is not a data race: the vma is undergoing init= ial setup, so it's not yet > > It is possible to make this API `&mut self` then? No because of pinning. And taking `self: Pin<&mut Self>` is obnoxious. > > + // shared. Additionally, `VmaNew` is `!Sync`, so it cannot be = used to write in parallel. > > + // The caller promises that this does not set the flags to an = invalid value. > > Does `VmaRef` has to be `!Sync`? I wonder if we should explicitly mark > `VmaNew` as `!Sync` so this is more explicitly correct. See above. Alice