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

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

On 6/18/26 21:25, Linus Torvalds wrote:
> On Thu, 18 Jun 2026 at 11:34, Andrew Morton <akpm@linux-foundation.org> wrote:
>>
>> Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude
>> hugetlb VMAs from the check for VM_SPECIAL.
> 
> This seems bogus.
> 
> If somebody sets DONTEXPAND, then that mapping *is* special, and
> userfaultfd should not mess with it.

Right, it's one kind of special.

> 
> It feels like hugetlbfs is just wrong to do this.
> 
> This has caused problems before, see MADV_DODUMP which has that same
> "hugetlb doesn't follow the rules" check.
> 
> What exactly is it that hugetlbfs wants that DONTEXPAND thing to be?

I tried digging into the history: hugetlb doesn't support VMA merging (or VMA
expansion through mremap), apparently because of hugetlb reservation
interactions. Just nasty.

So I guess for userfaultd at least the VMA mergability/expansion doesn't matter.
Hopefully.

> 
> That said, I don't like the VM_SPECIAL bit mask all that much, because
> it doesn't specify *what* kind of "special" it is.

Right. It's documented as

	"Special vmas that are non-mergable, non-mlock()able."

It's a bit weird that we throw both things into one bin but ok.

And we use it in other context, like

	#define VM_NO_KHUGEPAGED (VM_SPECIAL | VM_HUGETLB)


Maybe we should rename and possibly split that up, like

	VM_NO_MLOCK
	VM_NO_VMA_MERGE

And then have some generic "there are really special things mapped in here"

	VM_HAS_SPECIAL_MAPPINGS


This might become a bigger (overdue?) audit, because I wouldn't immediately be
able to tell why MLOCK would have a problem with VM_DONTEXPAND.

VMA_REMAP_FLAGS is also odd, because it talks about "Physically remapped pages
are special" but then also includes VM_DONTEXPAND.

Any suggestion?

-- 
Cheers,

David