Re: [PATCH v2 13/13] mm/mremap: convert mremap code to use vma_flags_t

"Vlastimil Babka (SUSE)" <[email protected]> Wed, 22 Jul 2026 18:15:11 +0200
Newsgroups org.kernel.vger.linux-fbdev,dev.linux.lists.virtualization,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.freedesktop.lists.intel-xe,org.freedesktop.lists.nouveau,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-mips,org.kernel.vger.linux-samsung-soc,org.kernel.vger.linux-sound,org.kernel.vger.linux-tegra,org.kvack.linux-mm,org.ozlabs.lists.linuxppc-dev,org.xenproject.lists.xen-devel
Message-ID <[email protected]>
On 7/11/26 20:45, Lorenzo Stoakes wrote:
> Replace use of the legacy vm_flags_t flags with vma_flags_t values
> throughout the mremap logic.
> 
> Note that, in replacing vm_flags_clear() (which takes the VMA write lock)
> with vma_clear_flags() and vma_clear_flags_mask() (which do not)
> respectively in unmap_source_vma() and dontunmap_complete(), we do not add
> a VMA write lock to account for htis.
> 
> This is because, in both cases, move_vma() is their calling function and
> this has already acquired the VMA write lock on vrm->vma whose VMA flags
> are being cleared.
> 
> In the case of vma_set_flags() in unmap_source_vma() we do need to do this
> - as prev and next were not necessarily write locked at this point.
> 
> Additionally update comments to reflect the changes to be consistent.
> 
> No functional change intended.
> 
> Reviewed-by: Zi Yan <[email protected]>
> Signed-off-by: Lorenzo Stoakes <[email protected]>

Reviewed-by: Vlastimil Babka (SUSE) <[email protected]>