Re: + userfaultfd-prevent-registration-of-special-vmas.patch added to mm-hotfixes-unstable branch

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

On 6/18/26 23:42, Linus Torvalds wrote:
> On Thu, 18 Jun 2026 at 14:07, David Hildenbrand (Arm) <david@kernel.org> wrote:
>>
>> Maybe we should rename and possibly split that up, like
>>
>>         VM_NO_MLOCK
>>         VM_NO_VMA_MERGE
> 
> That sounds saner, indeed.
> 
>> And then have some generic "there are really special things mapped in here"
>>
>>         VM_HAS_SPECIAL_MAPPINGS
> 
> I think maybe we should stop using "bitmasks of VM_xyz bits" and start
> moving to a "helper inlines for vma testing".

100%

> 
> That way we could make hugetlb not set DONTEXPAND at all, if we
> instead just introduce a
> 
>    static inline bool vma_can_merge(const struct vm_area_struct *vma)
>    {
>         if (vma->vm_flags & VM_SPECIAL)
>                 return false;
>         if (vma_is_hugetlb(vma))
>                 return false;
>         return true;
>     }

Yes. DONTEXPAND is a weird thing and I am afraid it's getting abused at other
places.

> 
> Ok, so that vma_is_hugetlb() thing doesn'ty exist - but we do have a

We have is_vm_hugetlb_page() that we should probably rename.

We probably need helpers for VMA vs. VMA flags, but I'd let Lorenzo figure that
out. (CC)

> VMA_HUGETLB_BIT to implement it. I wrote it that way mainly in an
> effort to make it all make sense logically.
> 
> And maybe we could get rid of VM_SPECIAL entirely at some point usign
> these kinds of helpers - by making "vma_can_merge()" and others that
> currently use VM_SPECIAL use the *actual* real bits explicitly and
> simply making each rule have simple and logical tests.

Yes. Or make them build on each other (vma_maps_special_pages() or whatever)

> 
> And the reason we should pass in the vma - not just vm_flags - is that
> often things like "is the vma anonymous" is part of the decision of
> what can be done.

Right, I think the problem is that sometimes (VMA modifications) we might have
the updated flags but not the updated VMA. But again, I'm sure Lorenzo could
figure that out.

> 
> I think this would make the code both more flexible _and_ more
> understandable if we had these kinds of helpers for different
> situations rather than have VM_SPECIAL kinds of flag combinations.
> 
> But I'm just throwing this out as an idea. Maybe there are better ways
> to deal with this. The current code does seem rather annoying.

Yes, thanks for raising that; it needs a proper rework with clear semantics.

-- 
Cheers,

David