On Fri, Oct 02, 2026 at 11:43:53PM +0200, David Hildenbrand (Arm) wrote:
> On 10/2/26 15:59, Lorenzo Stoakes (ARM) wrote:
> > On Fri, Oct 02, 2026 at 03:11:27PM +0200, David Hildenbrand (Arm) wrote:
> >> I'd be very happy if we could find a clear way to describe "this is what
> >> we call
> >> user memory: anon+pagecache", if that could come handy in such a context.
> >
> > Rather than arguing about it, how about shifting things to 'what backs the
> > mapping' and something like:
> >
> > /* big long kdoc... */
> > static inline bool vma_flags_is_mm_backed(const vma_flags_t *flags)
> > {
> > /* hugetlb is a fixed mapping, but the mm owns it entirely. */
> > if (vma_flags_is_hugetlb(flags))
> > return true;
> >
> > /*
> > * Kernel-owned mappings are populated by their owner, and fixed
> > mappings
> > * have a layout the mm cannot assume ordinary fault semantics over.
> > */
> > if (vma_flags_is_kernel_owned(flags) ||
> > vma_flags_is_fixed_mapping(flags))
> > return false;
> >
> > /* The mm has promised it may discard droppable memory at any time. */
> > return !vma_flags_test_single_mask(flags, VMA_DROPPABLE);
> > }
>
> In my other mail I was wondering whether we could use vma_is_mm_managed() to
> express !vma_is_kernel_owned(). Maybe vma_is_mm_backed() could fit into that
> picture.
Yeah, vma_is_mm_backed() = 'and the mm actually keeps it there' in effect :)
>
> Reading above I am still confused why something that expresses "backed" talks
> about "fixed mappings and ownership", sorry :(
I'll rework the kdoc to be clearer - I think with vma_is_mm_managed() the
picture actually becomes clearer.
>
> It's late here, and this is a hard nut to crack.
Yes :)
Thanks for taking the time with this, I know some of it is pretty heavy going.
>
> What we have here is:
>
> 1) Is this an ordinary MM-managed VMA. So far so good, I understand that.
> (with
> a twist what I just learned about things that map random allocated pages
> through -> fault, but so far so good)
Ack yeah. And ack on ->fault.
It feels like we let ->fault be FAR too permissive. In retrospect, arbitrarily
being able to put WHATEVER YOU WANT there was... unwise shall we say.
>
> 2) Is this MM "fixed" that makes expand/merge tricky, except if it's hugetlb
> where we can still handle it.
Yeah the trickiest bit is the 'don't expand'.
The hugetlb exception is ugh, but hugetlb was engineered terribly,
essentially 'stick something in with total disregard for everything in core
mm and make it an exception you just have to remember for everything'.
I hope we all learn some lessons about what not to do from hugetlb and uffd
:)
>
> I think VM_DONTEXPAND is also rather misnamed :( I assume it really means,
> using
> sel_mmap_policy_ops() as an example: the MM manages the things that are
> getting
> mapped in here (->fault), but the pages are not really pagecache/anon, but
> some
> other shit. So we cannot expand the mapping.
Yeah. And it is terribly named.
>
> Gah, so complicated.
>
> 3) Can the MM drop the pages at any time.
>
>
> I still think that 3) does not quite fit into that picture. Using something
> like
If you look at what the callers do it makes more sense - mlock pins pages,
ksm merges them, dump writes them out and uffd hands their faults to userspace.
All four need the page behind the mapping to be the mm's own and _still
there the next time they look_.
With that in place it's not stable so it's not right to let such callers
have access, and all the callers have to remember to check that.
>
> "vma_is_mm_backed" to say "this is mm-managed, but all things in there come
> from
> core-mm and not some other random shit people punch into ->fault" would work
> for me.
Yeah agreed, I will update the kdoc to be clear about that.
>
> (not sure if there is still some other way how someone could get random pages
> into a VMA ... or how to catch someone not setting the DONTEXPAND flag)
vm_insert_pages() + friends sets VMA_MIXEDMAP_BIT now and
vmf_insert_page_mkwrite() is DAX only (a follow up will make that a thing)
so it's the damn ->fault that's the only thing left now.
Right now I think that everyone that does something weird sets
VMA_DONTEXPAND_BIT.
It needs renaming to something like VMA_CUSTOM_FAULTED_BIT or
something. That's probably a terrible name but you get the idea... :)
>
> God, this is all such a confusing mess with so many ways of getting stuff
> messed
> up by other parts of the system. Thanks for working on cleaning that up.
No worries :)
The whole point of the series is to stop treating these flags as vague
things (which VM_SPECIAL symbolised the most) so a. we can make sensible
assumptions about flag combinations and b. people can use meaningful
semantic checks rather than guessing (sometimes wrong).
Hopefully the pain here is all worth it :)
Thanks again for reviewing!
I will respin with kdoc changes.
>
> --
> Cheers,
>
> David
--
Cheers, Lorenzo
