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

["David Hildenbrand (Arm)" <david@kernel.org>]

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

This is all super confusing and I don't think we should try to describe the
semantics that way.

Just imagine having udmabuf use a PFNMAP of folios obtained from shmem. For sure
the kernel could now change the shmem pages that are mapped in some ordinary VMA.


Likely we don't have to squeeze everything into a single helper that is hard to
describe.

Maybe we can pull parts of it into a separate helper with semantics that are
easier to describe?


vma_is_user_memory() && !vma_is_droppable_memory()

Although I am not sure user_memory is exactly precise (pagecache+anon) and what
we want? It's all super confusing (thanks for deciphering it).


> 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.
This is all confusing because persistent and volatile are established concept
when talking about memory. And see my example above, it's not even clear what it
means that "the kernel can modify something".

-- 
Cheers,

David