Re: [PATCH 27/39] mm: rename is_vm_hugetlb_page() to vma_is_hugetlb()

[Lorenzo Stoakes (ARM)]

On Wed, Sep 09, 2026 at 03:20:55PM +0200, Claudio Imbrenda wrote:
> On Wed, 9 Sep 2026 12:30:45 +0100
> "Lorenzo Stoakes (ARM)" <ljs@xxxxxxxxxx> wrote:
>
> > On Wed, Sep 09, 2026 at 01:22:07PM +0200, Claudio Imbrenda wrote:
> > > On Tue, 08 Sep 2026 21:01:31 +0100
> > > "Lorenzo Stoakes (ARM)" <ljs@xxxxxxxxxx> wrote:
> > >
> > > [please note that I had to prune the CC list quite aggressively because
> > > my SMTP server was not happy]
> >
> > Yeah sorry about that, I already pruned the list a LOT from what b4 wanted, and
> > still ended up with a ton of people (I consider maintainers for stuff I touch
> > the minimum cc, but also added mm reviewers).
>
> yeah I did not mean to fault you, I understand why the list was so
> long. mine was just a courtesy warning in case people reply to this
>
> [...]
>
> > > > @@ -247,7 +247,7 @@ static int __gmap_helper_unshare_zeropages(struct mm_struct *mm)
> > > >  		 * proof to catch unexpected zeropages in other mappings and
> > > >  		 * fail.
> > > >  		 */
> > > > -		if ((vma->vm_flags & VM_PFNMAP) || is_vm_hugetlb_page(vma))
> > > > +		if ((vma->vm_flags & VM_PFNMAP) || vma_is_hugetlb(vma))
> > >
> > > Would it be possible to replace this ^ with !vma_can_gup() ?
> > >
> > > (obviously not in this patch, since vma_can_gup() is only introduced at
> > > the end of the series)
> >
> > Sure, I could squash that into the 'use and apply vma_can_gup()' patch. Will do
> > on next respin!
>
> excellent, thanks!

Actually this isn't quite vma_can_gup(), as that will wrongly exclude VMAs with
VMA_IO_BIT set, and I think VMA_IO_BIT mappings can map the shared zeropage.

Maybe one to reassess on follow up?

>
> >
> > >
> > > >  			continue;
> > > >  		addr = vma->vm_start;
> > > >
> > >
> > > [...]
> >
> > --
> > Cheers, Lorenzo
>

--
Cheers, Lorenzo