Linux mm drops VM_SPECIAL for explicit VMA behaviour predicates

Linux memory management is shedding the long-standing VM_SPECIAL flag mask in favour of predicates that say what a VMA actually is, rather than lumping unrelated properties under one overloaded label.

Lorenzo Stoakes (ARM) posted a 38-patch series that removes VM_SPECIAL and VMA_SPECIAL_FLAGS entirely. Those bits had come to mean several different things at once: whether core mm or a driver owned the mapping, whether the range could expand or merge, whether get_user_pages should stay away, and assorted edge cases around mlock and migration. Drivers abused individual flags such as VM_IO, hugetlb sat awkwardly beside the special mask, and the word "special" already meant something else for VDSO, VVAR, THP, and folio lookup paths. Stoakes called the result "all rather a mess."

The series establishes hard invariants instead. Mappings managed by core mm may not set the IO bit or clear MAYWRITE from an mmap hook; the kernel now validates VMA state after every mmap and mmap_prepare. Mapping kernel memory must set MIXEDMAP. Call sites that once tested the special mask now ask whether a VMA is mm-managed, mm-backed, fixed, or mergeable. Several drivers (usbmon, scatterlist, hfi1, ALSA PCM status, defio, cmt_speech, uprobes, and the BPF arena) were updated to match the new rules, and fuse DAX dropped an unnecessary MIXEDMAP that had made it the odd one out among DAX implementations.

For in-tree code the changes are intended to be behavioural no-ops. Out-of-tree drivers that still mark an mm-managed mapping as IO will hit a WARN and fail the mmap. The practical payoff is clearer contracts for driver authors and fewer silent assumptions inside core mm about what any given flag combination really means.