Re: [PATCH v2 13/13] mm/mremap: convert mremap code to use vma_flags_t
"Vlastimil Babka (SUSE)" <[email protected]>
| Newsgroups | org.xenproject.lists.xen-devel,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-fbdev,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 |
|---|---|
| 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]>