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

[Lorenzo Stoakes (ARM)]

On Thu, Oct 01, 2026 at 02:36:40PM +0200, David Hildenbrand (Arm) wrote:
> On 9/17/26 18:22, Lorenzo Stoakes (ARM) wrote:
> > 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.

>
> >
> > Signed-off-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>
> > ---
> >  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