On Mon, Apr 26, 2021 at 02:36:26PM -0700, Mike Kravetz wrote: > On 4/26/21 2:16 PM, Peter Xu wrote: > > On Fri, Apr 23, 2021 at 01:33:08PM -0700, Mike Kravetz wrote: > >> On 3/22/21 5:50 PM, Peter Xu wrote: > >>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h > >>> index 92710600596e..4047fa042782 100644 > >>> --- a/include/linux/hugetlb.h > >>> +++ b/include/linux/hugetlb.h > >>> @@ -121,14 +121,15 @@ long follow_hugetlb_page(struct mm_struct *, struct vm_area_struct *, > >>> unsigned long *, unsigned long *, long, unsigned int, > >>> int *); > >>> void unmap_hugepage_range(struct vm_area_struct *, > >>> - unsigned long, unsigned long, struct page *); > >>> + unsigned long, unsigned long, struct page *, > >>> + unsigned long); > >>> void __unmap_hugepage_range_final(struct mmu_gather *tlb, > >>> struct vm_area_struct *vma, > >>> unsigned long start, unsigned long end, > >>> - struct page *ref_page); > >>> + struct page *ref_page, unsigned long zap_flags); > >>> void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma, > >>> unsigned long start, unsigned long end, > >>> - struct page *ref_page); > >>> + struct page *ref_page, unsigned long zap_flags); > >> > >> Nothing introduced with your patch, but it seems __unmap_hugepage_range_final > >> does not need to be in the header and can be static in hugetlb.c. > > > > It seems to be used in unmap_single_vma() of mm/memory.c? > > Sorry, that should have been __unmap_hugepage_range. No need for you to > address in this series. Ah yes; I'd rather add a patch if you won't object, since my series will touch that definition. > > >> > >> Everything else looks good, > >> > >> Reviewed-by: Mike Kravetz <mike.kravetz@xxxxxxxxxx> > > > > Please let me know whether you want my extra paragraph in the commit message, > > then I'll coordinate accordingly with the R-b. Thanks! > > Yes, please do add the extra paragraph. Will do. -- Peter Xu
