Re: [PATCH] mm/memory: fix hugetlb_zap_begin() call in zap_vma_range_batched()

[SJ Park <sj@kernel.org>]

On Thu, 3 Sep 2026 17:35:40 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:

> On Thu,  3 Sep 2026 17:00:26 -0700 SJ Park <sj@kernel.org> wrote:
> 
> > Commit f1fc44daf618 ("mm/hugetlb: don't lock private resv_map during
> > final unmap") added zap_details parameter to hugetlb_zap_begin().  But
> > the hugetlb_zap_begin() call in zap_vma_range_batched() is not updated.
> > As a result, build fails as below.  Fix it.
> > 
> >   CC      mm/memory.o
> > .../mm/memory.c: In function ‘zap_vma_range_batched’:
> > .../mm/memory.c:2308:9: error: too few arguments to function ‘hugetlb_zap_begin’
> >  2308 |         hugetlb_zap_begin(vma, &range.start, &range.end);
> >       |         ^~~~~~~~~~~~~~~~~
> > In file included from .../mm/memory.c:48:
> > .../include/linux/hugetlb.h:253:20: note: declared here
> >   253 | static inline void hugetlb_zap_begin(struct vm_area_struct *vma,
> >       |                    ^~~~~~~~~~~~~~~~~
> 
> You cleverly pulled during the ten-minute-window after I'd pushed this
> out in order to pull it onto my build-test-machine.

What a timing :)

I just found you pushed the tree again, after dropping the commit.  I confirmed
my build setup has no problem with it.  Sorry for making this noise.

> 
> There's probably a smarter way of doing this, not sure what though.
> 
> It doesn't happen often - I usually only need to push/pull the quilt
> patches (25-new).

No worry, indeed I never had this situation before.  And this was never a real
issue for me.


Thanks,
SJ

[...]