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
