Re: [PATCH v3 4/4] mm: introduce VMA flags bitmap type

[Pedro Falcato <pfalcato@suse.de>]

On Tue, Nov 25, 2025 at 10:01:02AM +0000, Lorenzo Stoakes wrote:
> It is useful to transition to using a bitmap for VMA flags so we can avoid
> running out of flags, especially for 32-bit kernels which are constrained
> to 32 flags, necessitating some features to be limited to 64-bit kernels
> only.
> 
> By doing so, we remove any constraint on the number of VMA flags moving
> forwards no matter the platform and can decide in future to extend beyond
> 64 if required.
> 
> We start by declaring an opaque types, vma_flags_t (which resembles
> mm_struct flags of type mm_flags_t), setting it to precisely the same size
> as vm_flags_t, and place it in union with vm_flags in the VMA declaration.
> 
> We additionally update struct vm_area_desc equivalently placing the new
> opaque type in union with vm_flags.
> 
> This change therefore does not impact the size of struct vm_area_struct or
> struct vm_area_desc.
> 
> In order for the change to be iterative and to avoid impacting performance,
> we designate VM_xxx declared bitmap flag values as those which must exist
> in the first system word of the VMA flags bitmap.
> 
> We therefore declare vma_flags_clear_all(), vma_flags_overwrite_word(),
> vma_flags_overwrite_word(), vma_flags_overwrite_word_once(),
> vma_flags_set_word() and vma_flags_clear_word() in order to allow us to
> update the existing vm_flags_*() functions to utilise these helpers.
> 
> This is a stepping stone towards converting users to the VMA flags bitmap
> and behaves precisely as before.
> 
> By doing this, we can eliminate the existing private vma->__vm_flags field
> in the vma->vm_flags union and replace it with the newly introduced opaque
> type vma_flags, which we call flags so we refer to the new bitmap field as
> vma->flags.
> 
> We update vma_flag_[test, set]_atomic() to account for the change also.
> 
> We adapt vm_flags_reset_once() to only clear those bits above the first
> system word providing write-once semantics to the first system word (which
> it is presumed the caller requires - and in all current use cases this is
> so).
> 
> As we currently only specify that the VMA flags bitmap size is equal to
> BITS_PER_LONG number of bits, this is a noop, but is defensive in
> preparation for a future change that increases this.
> 
> We additionally update the VMA userland test declarations to implement the
> same changes there.
> 
> Finally, we update the rust code to reference vma->vm_flags on update
> rather than vma->__vm_flags which has been removed. This is safe for now,
> albeit it is implicitly performing a const cast.
> 
> Once we introduce flag helpers we can improve this more.
> 
> No functional change intended.
> 
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Acked-by: Vlastimil Babka <vbabka@suse.cz>

FWIW, I'm not a huge fan of this vma_flags vs vm_flags and hope we can
get rid of this ASAP. But it's a necessary evil for now, anyway.

Reviewed-by: Pedro Falcato <pfalcato@suse.de>

-- 
Pedro