Re: [PATCH 13/13] mm/mremap: convert mremap code to use vma_flags_t
"Zi Yan" <[email protected]> Wed, 08 Jul 2026 22:28:00 -0400
| Newsgroups | gmane.linux.ports.tegra,gmane.linux.ports.mips,gmane.linux.kernel,gmane.linux.ports.ppc64.devel,gmane.comp.video.dri.devel,gmane.linux.ports.arm.kernel,gmane.linux.kernel.samsung-soc,gmane.comp.freedesktop.xorg.drivers.intel,gmane.linux.ports.arm.msm,gmane.comp.freedesktop.xorg.drivers.freedreno,gmane.comp.freedesktop.xorg.nouveau,gmane.linux.ports.arm.rockchip,gmane.comp.emulators.xen.devel,gmane.linux.kernel.aio.general,gmane.linux.file-systems,gmane.linux.kernel.mm,gmane.linux.sound |
|---|---|
| Message-ID | <[email protected]> |
On Thu Jul 2, 2026 at 12:07 PM EDT, Lorenzo Stoakes wrote: > On Thu, Jul 02, 2026 at 09:49:47PM +0800, Lance Yang wrote: >> >> On Mon, Jun 29, 2026 at 08:25:36PM +0100, Lorenzo Stoakes wrote: >> >Replace use of the legacy vm_flags_t flags with vma_flags_t values >> >throughout the mremap logic. >> > >> >Additionally update comments to reflect the changes to be consistent. >> > >> >No functional change intended. >> > >> >Signed-off-by: Lorenzo Stoakes <[email protected]> >> >--- >> >> The vm_flags_set() cases below spell out vma_start_write(), but the >> vm_flags_clear() cases don't? > > Yep as I said elsewhere, implicitly taking the lock is terrible and me do= ing > this is completely on purpose to get rid of that :) > > But I haven't been clear enough clearly, so I should put the argument as = to why > that's ok in the commit message. > > Will do so on respin. How about also add a comment to vma_clear*() telling us a lock is not needed and why like you explained a lock is needed for vma_set*()? This asymmetry could confuse people.=20 This patch looks good to me. Reviewed-by: Zi Yan <[email protected]> --=20 Best Regards, Yan, Zi