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 | gmane.comp.freedesktop.xorg.drivers.freedreno,gmane.linux.kernel.mm,gmane.linux.kernel,gmane.linux.ports.mips,gmane.linux.kernel.aio.general,gmane.linux.file-systems,gmane.linux.ports.ppc64.devel,gmane.comp.video.dri.devel,gmane.linux.kernel.samsung-soc,gmane.comp.freedesktop.xorg.drivers.intel,gmane.linux.ports.arm.msm,gmane.comp.freedesktop.xorg.nouveau,gmane.linux.ports.tegra,gmane.comp.emulators.xen.devel,gmane.linux.sound |
|---|---|
| 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]>