Thread (146 messages) 146 messages, 8 authors, 6d ago

Re: [PATCH v3 31/40] mm/vma: introduce vma[_flags]_is_persistent()

flat view

From: "David Hildenbrand (Arm)" <david@kernel.org>
Date: 2026-10-02 21:44:32
Also in: bpf, fuse-devel, kvm, kvm-riscv, kvmarm, linux-arch, linux-doc, linux-fbdev, linux-fsdevel, linux-mm, linux-perf-users, linux-rdma, linux-riscv, linux-s390, linux-scsi, linux-sound, linux-trace-kernel, linux-usb, lkml, selinux, sparclinux

On 10/2/26 15:59, Lorenzo Stoakes (ARM) wrote:
On Fri, Oct 02, 2026 at 03:11:27PM +0200, David Hildenbrand (Arm) wrote:
quoted
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.

Reading above I am still confused why something that expresses "backed" talks
about "fixed mappings and ownership", sorry :(

It's late here, and this is a hard nut to crack.

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)

2) Is this MM "fixed" that makes expand/merge tricky, except if it's hugetlb
   where we can still handle it.

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.

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

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

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

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.

-- 
Cheers,

David
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help