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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Fri, Oct 02, 2026 at 11:19:32PM +0200, David Hildenbrand (Arm) wrote:

> > So indeed, vs. user-owned.
>
> Right, I read "contents of the VMA are owned by the kernel rather than the core
> mm?" and that confused me, because the opposite of the kernel is to me not core-mm.
>
> Maybe it would be clearer to focus on the opposite direction, then we wouldn't
> have to find a word to describe "not core-mm".

Yeah, it is hard to know how to express that.

> > I think the issue here is you're confusing this with other things like the
> > rmap and refcounting, etc.
>
> I think it all weirdly interacts.
>
> In !vma_is_kernel_owned(), would we only expect ordinary folios
> (anon/pagecache/hugetlb/dax, maybe shared zero folio)?
>
> That's my best guess looking at
>
> 	return vma_flags_test_any(flags, VMA_PFNMAP_BIT, VMA_MIXEDMAP_BIT,
> 				  VMA_IO_BIT);
>
> So one option would be to focus instead on that aspect (folios that are managed
> by core-mm vs. random other stuff not managed by core-mm). But thinking about
> it, I'd prefer if we can leave the "folio" bits out, because COW mappings also
> map (some) folios. See below.

Mostly it does indeed come down to 'can I rely on core mm to do the refcounting,
mapcounting, rmap, etc.'

But folios are not quite there yet until the memdesc stuff is done as you say,
so best to leave that out of any description.

> > 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.
>
> Agreed. They are all special things and won't be folios in the future. (shmem
> mapped through PFN tells us to ignore its folio background and treat it just as
> some PFN range).

Yep the shmem mapped via pfnmap is a special case of the 'hands off the folios'
variety.

> > The distinction is - who put them there and who's allowed to change them
> > and who owns the lifecycle.
>
> Lol, I asked AI for better names and it told me "vma_is_special_mapping()".
> Thanks, I guess.

Yeah you see my point? :)

That's why I want to steer away from ordinary vs. 'not ordinary' (otherwise
known as special).

The semantics have to be meaningful more than that.

>
> I assume for the reverse, we really just want to say "just an ordinary core-mm
> vma that you would get from a simple mmap() as long as no weird non-mm drivers
> or subsystems are involved. Core MM fully manages this thing.".
>
> * vma_is_mm_managed()
> * vma_is_mm_controlled()

OK, great, that works!

I think vma_is_mm_managed() works best out of those two.

I'll update v4 to reflect that, I plan to send the respin out today before
LPC :)

> >>> 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

> >>> +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 :)
>
> Great, that helps to identify these things. I didn't look at all patches yet,
> but we should definitely document that.

You mean the fact that this is required? It's documented certainly insofar that
this series makes it a literal WARN_ON() error to do that ;)

I'm not sure exactly where you'd document it in the kernel documentation though.

But having this enforced now as a strict requirement is very powerful, because
it means core mm can assume things that before it couldn't due to drivers doing
'weird stuff'.

Which I think has been a large part of the problem with the VMA flags - not
being certain that VM_xxx means y because hey I remember that driver z does
weird stuff with it suddenly means the flag doesn't have a clear meaning any
more.

So this I think is a very useful step to take.

>
> >
> > Other than the DAX-only case below of course.
>
> Right, as DAX uses real folios.

Yup. And FUSE DAX now too :) Another 'weird byproduct of this series' that :P

> > I could also add a patch to this series to do that too if you wanted?
>
> We can do a follow up. Not giving others the chance to abuse these interfaces
> would be great.

OK cool, will add to todo!

--
Cheers, Lorenzo