On Fri, Oct 02, 2026 at 09:05:15AM +0200, David Hildenbrand (Arm) wrote:
> On 10/2/26 09:02, David Hildenbrand (Arm) wrote:
> > On 10/2/26 08:59, David Hildenbrand (Arm) wrote:
> >> On 9/17/26 18:22, Lorenzo Stoakes (ARM) wrote:
> >>> 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.

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

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

Reply via email to