Re: [PATCH] mm/userfaultfd: only allocate anon_vma in CoW mappings

[Kyle Zeng]

On Wed, Oct 14, 2026 at 03:51:22PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Wed, Oct 14, 2026 at 01:53:11PM +0200, David Hildenbrand (Arm) wrote:
> > As uffd_lock_vma() is part of the same lookup machinery and
> > also contains a misleading VM_SHARED check, change that one as well
> > directly for consistency.
> 
> OK, I think that one isn't _strictly necessary_, but while we're there,
> worth doing too, clearly.
> 
> We should also go through and convert the remaining !VM_SHARED checks ->
> vma_is_cow_mapping() too if possible, but that's a follow up, obviously!
> 
> >
> > A follow-up cleanup will stop taking the hugetlb_vma_lock_read(src_vma)
> > lock in copy_hugetlb_page_range() entirely. Further, the usage of
> 
> Hmm really? Is it possible to do that without the hugetlb lock?
> 
> It'd be good in general if we could get rid of that lock as a whole :) but maybe
> dreaming.
> 
> > VM_SHARED in userfaultfd code should be cleaned up later to focus on
> > CoW vs. non-CoW mappings.
> 
> I think also anywhere else in the kernel where this is done. An audit on that in
> general would be useful!
> 
> >
> > Reported-by: Kyle Zeng <kylebot@xxxxxxxxxx>
> > Fixes: 867a43a34ff8a ("userfaultfd: use per-vma locks in userfaultfd operations")
> > Cc: stable@xxxxxxxxxxxxxxx
> > Signed-off-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>
> 
> This LGTM, thanks for handling this!
> 
> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>
> 
> --
> Cheers, Lorenzo

I ran the patch through my system and did not find any issues with this
patch. Thanks for addressing this!

Reviewed-by: Kyle Zeng <kylebot@xxxxxxxxxx>