Re: [PATCH 13/13] mm/mremap: convert mremap code to use vma_flags_t
"Zi Yan" <[email protected]>
| Newsgroups | org.kernel.vger.linux-samsung-soc,dev.linux.lists.virtualization,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.freedesktop.lists.intel-xe,org.freedesktop.lists.nouveau,org.infradead.lists.linux-rockchip,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-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 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 doing > 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. This patch looks good to me. Reviewed-by: Zi Yan <[email protected]> -- Best Regards, Yan, Zi