Re: [PATCH v4 23/25] mm/vma: convert vma_modify_flags[_uffd]() to use vma_flags_t

Vlastimil Babka (SUSE)
2026-03-23T15:47:50Z

On 3/20/26 8:38 PM, Lorenzo Stoakes (Oracle) wrote:
> Update the vma_modify_flags() and vma_modify_flags_uffd() functions to
> accept a vma_flags_t parameter rather than a vm_flags_t one, and propagate
> the changes as needed to implement this change.
>
> Also add vma_flags_reset_once() in replacement of vm_flags_reset_once(). We
> still need to be careful here because we need to avoid tearing, so maintain
> the assumption that the first system word set of flags are the only ones
> that require protection from tearing, and retain this functionality.
>
> We can copy the remainder of VMA flags above 64 bits normally. But
> hopefully by the time that happens, we will have replaced the logic that
> requires these WRITE_ONCE()'s with something else.
>
> We also replace instances of vm_flags_reset() with a simple write of VMA
> flags. We are no longer perform a number of checks, most notable of all the
> VMA flags asserts becase:
>
> 1. We might be operating on a VMA that is not yet added to the tree.
>
> 2. We might be operating on a VMA that is now detached.
>
> 3. Really in all but core code, you should be using vma_desc_xxx().
>
> 4. Other VMA fields are manipulated with no such checks.
>
> 5. It'd be egregious to have to add variants of flag functions just to
> account for cases such as the above, especially when we don't do so for
> other VMA fields. Drivers are the problematic cases and why it was
> especially important (and also for debug as VMA locks were introduced),
> the mmap_prepare work is solving this generally.
>
> Additionally, we can fairly safely assume by this point the soft dirty
> flags are being set correctly, so it's reasonable to drop this also.
>
> Finally, update the VMA tests to reflect this.
>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>