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) <[email protected]>
Acked-by: Vlastimil Babka (SUSE) <[email protected]>
