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) <[email protected]>
> > ---
> > 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
