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 4C12DD6E2A4 for ; Thu, 21 Nov 2024 10:23:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D4BF76B0082; Thu, 21 Nov 2024 05:23:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D225D6B009B; Thu, 21 Nov 2024 05:23:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC3846B009C; Thu, 21 Nov 2024 05:23:55 -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 98C886B0082 for ; Thu, 21 Nov 2024 05:23:55 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 54B04160A8B for ; Thu, 21 Nov 2024 10:23:55 +0000 (UTC) X-FDA: 82809714918.12.89BA45B Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by imf01.hostedemail.com (Postfix) with ESMTP id 9B03B40005 for ; Thu, 21 Nov 2024 10:23:12 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mLZ0Ci8L; spf=pass (imf01.hostedemail.com: domain of aliceryhl@google.com designates 209.85.128.52 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=1732184386; 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=OlhoxgSKcYll6Lv3NUhKYXSAfrSERdcOsWs5wudsJzM=; b=Xdcbi/SJOPh+qfDv5GIfBU7E50y6XQ+pD4DxKiHv6YSDjZwkQLrBND7gKqzUwdWVCceGkd LNIW0qRPesMOuShM59A2fdWII82/EWYiaCzLD1qf7u/R6SKsIKG3RDH6LFQ79BKIVYAVHg RaTM9WydMH4Xta4v5eqRehzvT+/RDwo= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mLZ0Ci8L; spf=pass (imf01.hostedemail.com: domain of aliceryhl@google.com designates 209.85.128.52 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=1732184386; a=rsa-sha256; cv=none; b=ZjBl2htpIr3LFBPQETBRSD20cBRvbz1RmNBEPQl7GKMq3mBiAtk7ElB4dWD1ax5jJBPxe3 wWL0zG/ds7heA2MEaxHCx3hQ6CNtKE9mWZ/uaimocnEo0YWO4a8lmuCxMR3XYRXZnz86Wa Q4k5/t0fFh1zzBhZAY2XB4nYChXfakA= Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-4315c1c7392so5960065e9.1 for ; Thu, 21 Nov 2024 02:23:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1732184632; x=1732789432; 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=OlhoxgSKcYll6Lv3NUhKYXSAfrSERdcOsWs5wudsJzM=; b=mLZ0Ci8LLNrbJT+ZWsPyborYopHGjjFhkPnCHsnZ5gglNfB0KbAC6q5SwRduAzvOWP nSbZ5cECvKETStNyLIs+hhiHY8yFUw1KtbldXPg2cq6nqNwICiv0Z0xl8h9wmFhdOn69 a+UsF7JwDGacHVUhFmq5LDcUeW8RqptT5TfcMg123whO64SlQVGy46diRVm+ueplR+zZ /DLyjOWo8faccLmb2TiJ9JIqrJDUUg1Ew7ddVQcdZaW7D1YEVTOhEWnYy5hFAD2KZ3Vd oH8Lpas/2v4x6DsnmIDG7ctG7NV5l8n/H2utPGj0CEGH7oyorClPh+Gq42Crz5rcgwcK 0UCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732184632; x=1732789432; 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=OlhoxgSKcYll6Lv3NUhKYXSAfrSERdcOsWs5wudsJzM=; b=opvFlvpda3WG+/JC2i0amc0xS/+hlp/Fen+urFvISV1yoUXaXIoakdnvKyP/sjF5T8 dK/pi87V2cHf8wcJvPhgKYmmL4ePs2ydouDk52mHx14uq5QkN79wd5ekhg+Y46e87h6B q5zjDWnbskzvDYcGA/d588IMEslbhF567qxDc95C5yuKhBCZcPQYu5bVvWFXGIPRrDgP MwlAwVInQC9TvJzrgIt/Z7wwLhhlTLHM2s7GCA9AhpvbDg9WpmR9d7saKDJqYzX6/uhq mly7zEzHZNAKXGnXW9gObiUnWuxU6ymJPoltgffCXolHWOVnz0YVIuVxPoGxU3sPY22c TlPQ== X-Forwarded-Encrypted: i=1; AJvYcCU5YXnxR0ajYrP5lHvDvF1WhqA6Iz/r64Ty35P4GLSwBsomMsJLnNgm5NeuwD86PmsUN5KQ793jdQ==@kvack.org X-Gm-Message-State: AOJu0YzO0Btdu+IJuuXI4Bm4M/1OYY519xc1ELNuaKgIiI2ETxRyAQFb MNIRqtsfGt6o7OGm5Vih0xv6lT0XCo1GNZsyQwb2lG2uaHnlAfVfb6izVwe1MtcstRUHjmGlHcz ggch2CxD2Xrmw61VscR/zlPYh/0SU0UlYAANd X-Gm-Gg: ASbGncup8IRdN4yNmnUbWtuLIF360L1gL6sTmqglnvL53/1R3FCHD6taMq6geq2MyrY DM31ynW6vmZv74VfB1mlZu2Y9dwL/Fw7D3TXjG7fBHiIVLL/aoTVEtTGZvzRxCQ== X-Google-Smtp-Source: AGHT+IHg4W/WUKGS8b99/9IFak+Ih4XgWQHTn4uE6zc4bD/TotmtUxHVl01wgBvUz//vn3WMdD++hod39LRNOsPPkVw= X-Received: by 2002:a05:600c:b8a:b0:431:52a3:d9d9 with SMTP id 5b1f17b1804b1-43348904026mr58688315e9.0.1732184631834; Thu, 21 Nov 2024 02:23:51 -0800 (PST) MIME-Version: 1.0 References: <20241120-vma-v8-0-eb31425da66b@google.com> <20241120-vma-v8-2-eb31425da66b@google.com> In-Reply-To: From: Alice Ryhl Date: Thu, 21 Nov 2024 11:23:39 +0100 Message-ID: Subject: Re: [PATCH v8 2/7] mm: rust: add vm_area_struct methods that require read access To: Lorenzo Stoakes Cc: Miguel Ojeda , Matthew Wilcox , Vlastimil Babka , John Hubbard , "Liam R. Howlett" , Andrew Morton , Greg Kroah-Hartman , Arnd Bergmann , Christian Brauner , Alex Gaynor , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , linux-kernel@vger.kernel.org, linux-mm@kvack.org, rust-for-linux@vger.kernel.org, Andreas Hindborg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 9B03B40005 X-Stat-Signature: os9pkhnt5y6qxs6jbdjzo8p6un7b943u X-Rspam-User: X-HE-Tag: 1732184592-896567 X-HE-Meta: U2FsdGVkX1/2+EvKdxbx0obpwgQPTHZ4OPCwkf11zC8qFgB+enJqyQOIo0j35SADeT8XFwm9jn5Gsv9M/TRnNGT8jH+p5UwXpyQ/5zg8CXc6ybV2a/6STcjFZjWqwk2LswRpvIK1uI86kko5AedcSin9StBcVAntAbWXK8fh99rLtMBUWNosURK9uS60vv8R6TUFN3ZtKf0axZn/1aew2yIcgcvXTZddun0/7a1irQLVNEz6gjQPOilG9pY5DfGo+0ZWaoc0d+F2+Q/rC3iBIDBm65h+N5ZfNcnDdyMzzyDFP9MmIn5tZTQtXdF9/YTzuNAq7uG9dVNf7aG3XxU8lT2fG3kiWjNGpEyrF19oZf7xXH67EaP2AeJAwC0HWaJDyAphwJSZbSHZ7zntE7lKdIMnLnFA1If9WvvB5Eek7o1PEwODWp2CamzAdU9tgooNUmtT6jLHkdGshb+XT49reQBGW4aY1nAFcpnWTU8tcguo5hFCgOp8POoUWqWhRN1pLWYHcel/2yiwB/5mfUyfcj53L2atj95+gOfJdQEnOeJP7tKDWvC5uc8kQq/wPoB6fx05F/ZyYJBJQUDWL+DlfSSnq1QzTRIiP3iyxkMHw4gPk42qEtLIDYe1A5qxutb71xIYJNw9rHAU5viahwZ6noJWzqJaJHVt9leyr7l/kPa8LSrSKvHQiBsN71JLHiaPW+4TlvrGpIL9oMZVjYosqPTIryW2uaPx4CLE/Ckem73iM8nQLqQywtg152ygXqX/k2T8G8c+I1eYW6lb7pTDH65fim2LwmD+5PcoHTEFjxbFrK0eTk8WFhctc69EcmAFtFvPIhH/dmPYYz5qd2KPXR8ttW7jRvQLNrxIntGYcF100laecDPuJyd9VrciKyB68c3pfRIjTIlaJnzXZX5HWQNU6DJXx/As26AY04pAEMuBJyXUHq0MQvc14Fa7gkDN8H/RZLFV4hvHLl1aAip b0X54/sQ jmr6RGG/Tanbt9tKOexMRxbiGpGYAm5fyNEeEmbXXSzMz8b8zbzixFgLuGslSOiKF307usykzTnVFJfQF3lr7yNQqH2DqWFCKqL3vucvmiZxqzdlXkGJPb/nlvMOUT12phPYGh0bO0BK4wtXnVpO2przd27DTbvzjWPJyOOWOhOk8fDflCw+ounL3QkL6WqC/vTqX43o2eDX1ht1ANTMYtGumoVYuuxrtVHhqcOEnp34oPLHeuCzJI3UbnC1HGOFmVqQLjJPZVudWT4XXdfDR1b/TFKJKjIhmmda3ZHBeZmXMcu9x0uOUNwSbPT59ftflf2c0rYgOPmSEIvkeQquSkcgyapVQEXYvhvLnJP8JbCYKrK8LNTiFnRq4gBUnAA8vm2Klj7Qn5nTNXnrA7cpxswMflewZkh98CblsuOa273hsFudUllu1NdZq7C77pHDFQvGU X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 Wed, Nov 20, 2024 at 8:07=E2=80=AFPM Lorenzo Stoakes wrote: > > On Wed, Nov 20, 2024 at 02:49:56PM +0000, Alice Ryhl wrote: > > 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). > > This is pure nit and not important but... > > I know we screwed up naming in mm, with the god awful vm_area_struct (we > abbreviate, for 2 letters, get bored, stop abbreviating, but throw in a > struct for a laugh) or 'VMA', but I wonder if this would be better as > VmaRef? Then again that's kinda terrible too. > > Sorry about that. I mean this isn't hugely important + ultimately _our > fault_. > > VirtualMemoryAreaRef is worse... VirtMemAreaRef? OK. Maybe VMAreaRef is t= he > least bad... Happy to use whichever name you prefer. :) > > Additionally, a vma_lookup method is added to the mmap read guard, whic= h > > enables you to obtain a &VmAreaRef in safe Rust code. > > > > Signed-off-by: Alice Ryhl > > --- > > rust/helpers/mm.c | 6 ++ > > rust/kernel/mm.rs | 21 ++++++ > > rust/kernel/mm/virt.rs | 171 +++++++++++++++++++++++++++++++++++++++++= ++++++++ > > 3 files changed, 198 insertions(+) > > > > diff --git a/rust/helpers/mm.c b/rust/helpers/mm.c > > index 7201747a5d31..7b72eb065a3e 100644 > > --- a/rust/helpers/mm.c > > +++ b/rust/helpers/mm.c > > @@ -37,3 +37,9 @@ void rust_helper_mmap_read_unlock(struct mm_struct *m= m) > > { > > mmap_read_unlock(mm); > > } > > + > > +struct vm_area_struct *rust_helper_vma_lookup(struct mm_struct *mm, > > + unsigned long addr) > > +{ > > + return vma_lookup(mm, addr); > > +} > > I wonder whether we want to abstract some of the VMA iterator stuff, > because it's inefficient to look up VMAs by doing this each time if you a= re > looking at, for instance, adjacent VMAs. > > But perhaps reasonable to defer doing that to later work? Yeah, that should probably be deferred. Binder only has one vma per mm, so iteration is not useful. > > diff --git a/rust/kernel/mm.rs b/rust/kernel/mm.rs > > index 84cba581edaa..ace8e7d57afe 100644 > > --- a/rust/kernel/mm.rs > > +++ b/rust/kernel/mm.rs > > @@ -12,6 +12,8 @@ > > }; > > use core::{ops::Deref, ptr::NonNull}; > > > > +pub mod virt; > > + > > /// A wrapper for the kernel's `struct mm_struct`. > > /// > > /// Since `mm_users` may be zero, the associated address space may not= exist anymore. You can use > > @@ -210,6 +212,25 @@ pub struct MmapReadGuard<'a> { > > _nts: NotThreadSafe, > > } > > > > +impl<'a> MmapReadGuard<'a> { > > + /// Look up a vma at the given address. > > + #[inline] > > + pub fn vma_lookup(&self, vma_addr: usize) -> Option<&virt::VmAreaR= ef> { > > Kind of lovely to have functions under the read guard and then knowing th= at > hey - we must hold the read lock to be able to do this. > > Imagine, a programming language with actual types... :P :) > > + // SAFETY: We hold a reference to the mm, so the pointer must = be valid. Any value is okay > > + // for `vma_addr`. > > + let vma =3D unsafe { bindings::vma_lookup(self.mm.as_raw(), vm= a_addr as _) }; > > Why do we say 'as _' here? This is an integer cast where the target type of the cast is inferred by the compiler. It will go away once this lands: https://lore.kernel.org/rust-for-linux/20240913213041.395655-1-gary@garyguo= .net/ > > + > > + if vma.is_null() { > > + None > > + } else { > > + // SAFETY: We just checked that a vma was found, so the po= inter is valid. Furthermore, > > + // the returned area will borrow from this read lock guard= , so it can only be used > > + // while the mmap read lock is still held. > > Lovely! > > > + unsafe { Some(virt::VmAreaRef::from_raw(vma)) } > > + } > > + } > > +} > > + > > impl Drop for MmapReadGuard<'_> { > > #[inline] > > fn drop(&mut self) { > > diff --git a/rust/kernel/mm/virt.rs b/rust/kernel/mm/virt.rs > > new file mode 100644 > > index 000000000000..1e755dca46dd > > --- /dev/null > > +++ b/rust/kernel/mm/virt.rs > > @@ -0,0 +1,171 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > + > > +// Copyright (C) 2024 Google LLC. > > + > > +//! Virtual memory. > > Trivial rust q again but does this result in a heading in generated docs = or > something? Yes, this becomes module documentation. Check out: https://rust.docs.kernel.org/kernel/ or try out `make LLVM=3D1 rustdoc` > > +use crate::{bindings, 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. > > Might be worth mentioning here that you have yet to abstract the vma lock= ? I do that in the next patch. > > +#[repr(transparent)] > > +pub struct VmAreaRef { > > + vma: Opaque, > > +} > > + > > +// Methods you can call when holding the mmap or vma read lock (or str= ong). They must be usable no > > +// matter what the vma flags are. > > typo: 'or strong' -> 'or stronger'. > > Nitty, but perhaps say 'Methods must be usable' rather than 'they' to be > totally clear. Will reword. > > +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 read lock > > + /// (or stronger) is held for at least the duration of 'a. > > Well, VMA locks make this more complicated, in that we can just hold a VM= A > lock. But again, perhaps worth doing this incrementally and just talk abo= ut > mmap locks to start with. > > However since we reference VMA locks elsewhere, we should reference them > here (and probably worth mentioning that they are not yet abstracted). Oh I forgot to update this, it should say "mmap or vma read lock". > > + #[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() > > + } > > + > > + /// 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 _ } > > Hm what's up with this __bindgen_anon_N stuff? Whenever you have a `struct { ... }` or `union { ... }` in the middle of a struct, bindgen generates additional types for them because Rust doesn't have a direct equivalent. > > + } > > + > > + /// Returns the start address of the virtual memory area. > > + #[inline] > > + pub fn start(&self) -> usize { > > Is usize guranteed to be equivalent to unsigned long? They are guaranteed to have the same size, yes. But again, right now `unsigned long` is being translated to whichever one of u32 or u64 has the same size as usize, instead of just being translated to usize. Thus the annoying casts. We can get rid of them as soon as https://lore.kernel.org/rust-for-linux/20240913213041.395655-1-gary@garyguo= .net/ lands. > > + // 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 end address of the virtual memory area. > > Worth mentioning that it's an _exclusive_ end. Sure, I'll add that. > > + #[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 _ } > > + } > > + > > + /// Unmap pages in the given page range. > > This needs some more description, as 'unmapping' pages is unfortunately a= n > overloaded term in the kernel and this very much might confuse people as > opposed to e.g. munmap()'ing a range. > > I'd say something like 'clear page table mappings for the range at the le= af > level, leaving all other page tables intact, freeing any memory reference= d > by the VMA in this range (anonymous memory is completely freed, file-back= ed > memory has its reference count on page cache folio's dropped, any dirty > data will still be written back to disk as usual)'. Sure, will add that to the docs. > > + #[inline] > > + pub fn zap_page_range_single(&self, address: usize, size: usize) { > > + // SAFETY: By the type invariants, the caller has read access = to this VMA, which is > > + // sufficient for this method call. This method has no require= ments on the vma flags. Any > > + // value of `address` and `size` is allowed. > > + unsafe { > > + bindings::zap_page_range_single( > > Hm weirdly I see this in rust/bindings/bindings_generated.rs but not in > rust/helpers/mm.c is this intended? > > Is this meant to be generated _from_ somewhere? Is something missing for > that? The bindings_generated.rs file is generated at built-time from C headers. The zap_page_range_single is a real function, not a fake static inline header-only function, so bindgen is able to generate it without anything in rust/helpers. > > + self.as_ptr(), > > + address as _, > > + size as _, > > + core::ptr::null_mut(), > > + ) > > + }; > > + } > > +} > > + > > +/// The integer type used for vma flags. > > +#[doc(inline)] > > +pub use bindings::vm_flags_t; > > Where do you declare this type? It's declared in include/linux/mm_types.h > > + > > +/// All possible flags for [`VmAreaRef`]. > > Well you've not specified all as they're some speciailist ones and ones > that depend on config flags, so maybe worth just saying 'core' flags? Sure. > > +pub mod flags { > > Pure rust noobie question (again...) but what is a 'mod'? It's a module. > > + use super::vm_flags_t; > > + use crate::bindings; > > + > > + /// No flags are set. > > + pub const NONE: vm_flags_t =3D bindings::VM_NONE as _; > > This is strictly not a flag, as is the 0 value (and is used 'cleverly' in > kernel code when we have flags that are defined under some circumstances > but not others, where we can then assign these values to VM_NONE if not > available, ensuring all |=3D ... operations are no-ops and all & > ... expressions evaluate to false) but I guess it doesn't matter all too > much right? Ultimately it's just a bunch of integer constants. We can include or exclude whichever ones we prefer. > > + /// Mapping allows reads. > > + pub const READ: vm_flags_t =3D bindings::VM_READ as _; > > + > > + /// Mapping allows writes. > > + pub const WRITE: vm_flags_t =3D bindings::VM_WRITE as _; > > + > > + /// Mapping allows execution. > > + pub const EXEC: vm_flags_t =3D bindings::VM_EXEC as _; > > + > > + /// Mapping is shared. > > + pub const SHARED: vm_flags_t =3D bindings::VM_SHARED as _; > > + > > + /// Mapping may be updated to allow reads. > > + pub const MAYREAD: vm_flags_t =3D bindings::VM_MAYREAD as _; > > + > > + /// Mapping may be updated to allow writes. > > + pub const MAYWRITE: vm_flags_t =3D bindings::VM_MAYWRITE as _; > > + > > + /// Mapping may be updated to allow execution. > > + pub const MAYEXEC: vm_flags_t =3D bindings::VM_MAYEXEC as _; > > + > > + /// Mapping may be updated to be shared. > > + pub const MAYSHARE: vm_flags_t =3D bindings::VM_MAYSHARE as _; > > + > > + /// Page-ranges managed without `struct page`, just pure PFN. > > + pub const PFNMAP: vm_flags_t =3D bindings::VM_PFNMAP as _; > > + > > + /// Memory mapped I/O or similar. > > + pub const IO: vm_flags_t =3D bindings::VM_IO as _; > > + > > + /// Do not copy this vma on fork. > > + pub const DONTCOPY: vm_flags_t =3D bindings::VM_DONTCOPY as _; > > + > > + /// Cannot expand with mremap(). > > + pub const DONTEXPAND: vm_flags_t =3D bindings::VM_DONTEXPAND as _; > > + > > + /// Lock the pages covered when they are faulted in. > > + pub const LOCKONFAULT: vm_flags_t =3D bindings::VM_LOCKONFAULT as = _; > > + > > + /// Is a VM accounted object. > > + pub const ACCOUNT: vm_flags_t =3D bindings::VM_ACCOUNT as _; > > + > > + /// should the VM suppress accounting. > > + pub const NORESERVE: vm_flags_t =3D bindings::VM_NORESERVE as _; > > + > > + /// Huge TLB Page VM. > > + pub const HUGETLB: vm_flags_t =3D bindings::VM_HUGETLB as _; > > + > > + /// Synchronous page faults. > > Might be worth mentioning that this is DAX-specific only. Will add. > > + pub const SYNC: vm_flags_t =3D bindings::VM_SYNC as _; > > + > > + /// Architecture-specific flag. > > + pub const ARCH_1: vm_flags_t =3D bindings::VM_ARCH_1 as _; > > + > > + /// Wipe VMA contents in child.. > > Typo '..' - also probably worth saying 'wipe VMA contents in child on > fork'. Will add. > > + pub const WIPEONFORK: vm_flags_t =3D bindings::VM_WIPEONFORK as _; > > + > > + /// Do not include in the core dump. > > + pub const DONTDUMP: vm_flags_t =3D bindings::VM_DONTDUMP as _; > > + > > + /// Not soft dirty clean area. > > + pub const SOFTDIRTY: vm_flags_t =3D bindings::VM_SOFTDIRTY as _; > > + > > + /// Can contain `struct page` and pure PFN pages. > > + pub const MIXEDMAP: vm_flags_t =3D bindings::VM_MIXEDMAP as _; > > + > > + /// MADV_HUGEPAGE marked this vma. > > + pub const HUGEPAGE: vm_flags_t =3D bindings::VM_HUGEPAGE as _; > > + > > + /// MADV_NOHUGEPAGE marked this vma. > > + pub const NOHUGEPAGE: vm_flags_t =3D bindings::VM_NOHUGEPAGE as _; > > + > > + /// KSM may merge identical pages. > > + pub const MERGEABLE: vm_flags_t =3D bindings::VM_MERGEABLE as _; > > +} > > > > I'd say these comments are a bit sparse and need more detail, but they ar= e > literally comments from include/linux/mm.h and therefore, again, our fau= lt > so this is fine :) Happy to add more if you tell me what you'd like to see. ;) Alice