Re: [PATCH v3 15/40] mm/vma: add vma[_flags]_is_kernel_owned() predicates

On Thu, Oct 01, 2026 at 02:36:40PM +0200, David Hildenbrand (Arm) wrote:

On 9/17/26 18:22, Lorenzo Stoakes (ARM) wrote:

quoted

Rather than referring to VMA flags with uncertain meaning, add a new
predicate that explicitly describes what possession of the VMA_PFNMAP_BIT
or VMA_MIXEDMAP_BIT flags mean, and then refer to that function for
determining VMA mergeability.

Either flag means the contents of the mapping are owned by the kernel,
usually a driver, rather than by the core mm: the memory may be MMIO,
kernel-allocated pages or even ordinary pages the driver maps itself, but
the core must not populate, reclaim, migrate, copy-on-write or merge the
range on its own initiative.

We initially also include VMA_IO_BIT here, as by implication, these must be
kernel-owned. (mlock() also sets VMA_IO_BIT transiently on ordinary VMAs
while locking them, which is addressed later in this series.)

However the intent is to in future remove this, as no mapping should be
marked as an I/O mapping without also being marked with VMA_PFNMAP_BIT.

This forms the basis of further work intended to improve how we express VMA
properties such as this.

Also update the VMA userland tests to reflect the change.

No functional change intended.

Of course I have to bitch about the naming :)

Yup :)

Intuitively: kernel owned vs ... user owned?

No, it's kernel owned vs core-mm owned.

I would say somebody who does:

	ptr = malloc(4096);

Would think of that memory as 'owned' by them in the sense that they
control the lifetime, they established its attributes, etc.

So indeed, vs. user-owned.

Which implies core-mm is not part of the kernel?

Yes, this is confusing. ;)

I think what you're missing here is what _creates_ or _establishes_ the mapping.

Intuitively, if I do:

	ptr = kmalloc(GFP_KERNEL);

I, whether I am in the core kernel, or a driver, or whatever own it in any
meaningful sense of the word.

I think the issue here is you're confusing this with other things like the
rmap and refcounting, etc.

I assume you're coming from "map_kernel_pages*", but that's rather "kernel
memory" and not "kernel owned".

Usually we say "driver owned" when not talking about pagecache/anon. Or user vs.
kernel memory.

I think it would only add confusion:

VDSO/VVAR, perf ring buffers, shmem mapped via PFN map, uprobes, etc. are
all in this category and I doubt people would consider those driver-owned.

So is it really all about "is this (excluding CoW) no ordinary user memory that
we would track through the rmap" ?

VMA_MIXEDMAP_BIT mappings can be refcounted and rmapped so that's not a
correct description.

The distinction is - who put them there and who's allowed to change them
and who owns the lifecycle.

quoted

Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
---
 include/linux/mm.h              | 56 ++++++++++++++++++++++++++++++++++++++++-
 tools/testing/vma/include/dup.h | 29 ++++++++++++++++++++-
 2 files changed, 83 insertions(+), 2 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 2a92193ac6a5..cab29d6e15c1 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h

@@ -1612,6 +1612,44 @@ static inline bool vma_is_shared_maywrite(const struct vm_area_struct *vma)
 	return is_shared_maywrite(&vma->flags);
 }

+/**
+ * vma_flags_is_kernel_owned() - Do the specified VMA flags indicate that the
+ * contents of the VMA are owned by the kernel rather than the core mm?
+ * @flags: The VMA flags to test.
+ *
+ * A kernel-owned mapping is one whose contents are established and controlled
+ * by the kernel, typically a driver, rather than by the core mm's fault and
+ * rmap machinery.
+ *
+ * The mapping may be memory-mapped I/O, kernel-allocated pages or ordinary
+ * pages the owner has chosen to map itself (shmem via a PFN map, for instance).
+ *
+ * In all cases the core mm must not populate, reclaim, migrate, copy-on-write
+ * or merge it of its own accord.
+ *
+ * Pages mapped this way are not necessarily reference counted or map counted.
+ *
+ * Returns: true if the flags indicate a kernel-owned mapping.
+ */
+static inline bool vma_flags_is_kernel_owned(const vma_flags_t *flags)
+{
+	return vma_flags_test_any(flags, VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT,
+				  VMA_IO_BIT);

I thought we have cases where we drivers insert pages and neither set
VMA_PFNMAP_BIT nor VMA_MIXEDMAP_BIT.

There were 4 - defio, cmt_speech, uprobes and the bpf arena, and I fixed
all of them :)

Other than the DAX-only case below of course.

It's not correct behaviour and part of the point of this series is to
structurally _forbid_ illegal behaviour by drivers.

I assume vmf_insert_page_mkwrite() is fine because it is DAX doing it (should we
limit this interface to DAX?).

That is a DAX-only thing and DAX is precisely a case that should not be
kernel-owned (and isn't!)

This series actually fixes the FUSE case too, restricting this interface to
DAX only seems like a sensible follow up as well.

I could also add a patch to this series to do that too if you wanted?

--
Cheers, Lorenzo