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

On Fri, Oct 02, 2026 at 09:05:15AM +0200, David Hildenbrand (Arm) wrote:

On 10/2/26 09:02, David Hildenbrand (Arm) wrote:

quoted

On 10/2/26 08:59, David Hildenbrand (Arm) wrote:

quoted

On 9/17/26 18:22, Lorenzo Stoakes (ARM) wrote:

quoted

Introduce vma[_flags]_is_persistent() for the purposes of identifying
mappings that are persistent in the sense that bytes to the mapping stay
there, and bytes read from the mapping are the same unless changed by
actions taken by userland.

That's extremely confusing, sorry. We have to find a better name for that.

Is this really all about user pages (pagecache, anon) that we would find through
the rmap?

No, see below.

quoted

quoted

It's also about droppable mappings AFAIKs. How many more users will we have for
that function?

Anything that requires stuff not to be dropped behind the user's back, which is
at least 4 cases!

That being open-coded all over the place is a problem I think, and I think stuff
like the PMD device private are a reminder that open-coding all over can cause
problems.

quoted

If it's "no others" then please don't add a helper function with misleading
names for it and just keep the special "dumpable" check in the new form in
madvise_vma_behavior().

Talking to myself ... the more usage I see of the vma_is_persistent() the more I
think this shouldn't be a helper at all. Especially not one with such a
confusing name :P

There are 4 open-coded checks that test four ad-hoc flag combinations checking
for the same thing - 'can the kernel or a driver change things or discard stuff
behind my back?'

So abstracting that to a helper, alongside the other 'let's ask based on
semantics' helpers, seems sensible.

Maybe invert the meaning to make it clearer?

	vma_kernel_may_change_contents()?

vma_contents_may_change() is shorter but easily confused with something being
writable by userland etc.

Or maybe:

	vma_is_volatile()

?

Which is analogous to the meaning of the volatile keyword.

--
Cheers,

David

--
Cheers, Lorenzo