| Message ID | 20220812084921.409142-1-haiyue.wang@intel.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v1] mm: migration: fix the FOLL_GET failure on following huge page | expand |
On Fri, 12 Aug 2022 16:49:21 +0800 Haiyue Wang <haiyue.wang@intel.com> wrote: > Not all huge page APIs support FOLL_GET option, so the __NR_move_pages > will fail to get the page node information for huge page. Which ones need fixing? What are the user-visible runtime effects of this bug? Is a -stable backport warranted? > This is an temporary solution to mitigate the racing fix. > > After supporting follow huge page by FOLL_GET is done, this fix can be > reverted safely. >
> -----Original Message----- > From: Andrew Morton <akpm@linux-foundation.org> > Sent: Sunday, August 14, 2022 07:29 > To: Wang, Haiyue <haiyue.wang@intel.com> > Cc: linux-mm@kvack.org; linux-kernel@vger.kernel.org; david@redhat.com; linmiaohe@huawei.com; Huang, > Ying <ying.huang@intel.com>; songmuchun@bytedance.com; naoya.horiguchi@linux.dev > Subject: Re: [PATCH v1] mm: migration: fix the FOLL_GET failure on following huge page > > On Fri, 12 Aug 2022 16:49:21 +0800 Haiyue Wang <haiyue.wang@intel.com> wrote: > > > Not all huge page APIs support FOLL_GET option, so the __NR_move_pages > > will fail to get the page node information for huge page. > > Which ones need fixing? 1. 'follow_huge_pud' arch/s390/mm/hugetlbpage.c 2. 'follow_huge_addr' arch/ia64/mm/hugetlbpage.c 3. 'follow_huge_pgd' mm/hugetlb.c And I found that only 'pud' and 'pmd' need to check 'is_vm_hugetlb_page' like: pud_huge(*pud) && is_vm_hugetlb_page(vma) pmd_huge(pmdval) && is_vm_hugetlb_page(vma) So I'm not sure whether my patch can cover 2 & 3 for other huge page use cases except by hugetlbfs. > > What are the user-visible runtime effects of this bug? > In my test, the '__NR_move_pages' system call will return '-2' for 1GB huge page memory map when dump the page node information. [Test on linux-5.19 stable] > Is a -stable backport warranted? Yes. Since the mainline has introduced the new patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3218f8712d6bb The backported needs to rebase like for 5.19: - if (page && !is_zone_device_page(page)) { + if (page) { > > > This is an temporary solution to mitigate the racing fix. > > > > After supporting follow huge page by FOLL_GET is done, this fix can be > > reverted safely. > >
> -----Original Message----- > From: Wang, Haiyue > Sent: Sunday, August 14, 2022 14:20 > To: Andrew Morton <akpm@linux-foundation.org> > Cc: linux-mm@kvack.org; linux-kernel@vger.kernel.org; david@redhat.com; linmiaohe@huawei.com; Huang, > Ying <ying.huang@intel.com>; songmuchun@bytedance.com; naoya.horiguchi@linux.dev > Subject: RE: [PATCH v1] mm: migration: fix the FOLL_GET failure on following huge page > > > -----Original Message----- > > From: Andrew Morton <akpm@linux-foundation.org> > > Sent: Sunday, August 14, 2022 07:29 > > To: Wang, Haiyue <haiyue.wang@intel.com> > > Cc: linux-mm@kvack.org; linux-kernel@vger.kernel.org; david@redhat.com; linmiaohe@huawei.com; Huang, > > Ying <ying.huang@intel.com>; songmuchun@bytedance.com; naoya.horiguchi@linux.dev > > Subject: Re: [PATCH v1] mm: migration: fix the FOLL_GET failure on following huge page > > > > On Fri, 12 Aug 2022 16:49:21 +0800 Haiyue Wang <haiyue.wang@intel.com> wrote: > > > > > Not all huge page APIs support FOLL_GET option, so the __NR_move_pages > > > will fail to get the page node information for huge page. > > > > Is a -stable backport warranted? > > Yes. > > Since the mainline has introduced the new patch: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3218f8712d6bb > Looks like 'is_zone_device_page' will cause 'FOLL_GET' page reference count issue, which should call 'put_page' before call branch jump. try_grab_page --> if (flags & FOLL_GET) folio_ref_inc(folio); Or I misunderstood the 'is_zone_device_page' ? ;-) > The backported needs to rebase like for 5.19: > > - if (page && !is_zone_device_page(page)) { > + if (page) { > > > > > >
diff --git a/mm/migrate.c b/mm/migrate.c index 6a1597c92261..581dfaad9257 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -1848,6 +1848,7 @@ static void do_pages_stat_array(struct mm_struct *mm, unsigned long nr_pages, for (i = 0; i < nr_pages; i++) { unsigned long addr = (unsigned long)(*pages); + unsigned int foll_flags = FOLL_DUMP; struct vm_area_struct *vma; struct page *page; int err = -EFAULT; @@ -1856,8 +1857,12 @@ static void do_pages_stat_array(struct mm_struct *mm, unsigned long nr_pages, if (!vma) goto set_status; + /* Not all huge page follow APIs support 'FOLL_GET' */ + if (!is_vm_hugetlb_page(vma)) + foll_flags |= FOLL_GET; + /* FOLL_DUMP to ignore special (like zero) pages */ - page = follow_page(vma, addr, FOLL_GET | FOLL_DUMP); + page = follow_page(vma, addr, foll_flags); err = PTR_ERR(page); if (IS_ERR(page)) @@ -1865,7 +1870,8 @@ static void do_pages_stat_array(struct mm_struct *mm, unsigned long nr_pages, if (page && !is_zone_device_page(page)) { err = page_to_nid(page); - put_page(page); + if (foll_flags & FOLL_GET) + put_page(page); } else { err = -ENOENT; }
Not all huge page APIs support FOLL_GET option, so the __NR_move_pages will fail to get the page node information for huge page. This is an temporary solution to mitigate the racing fix. After supporting follow huge page by FOLL_GET is done, this fix can be reverted safely. Fixes: 4cd614841c06 ("mm: migration: fix possible do_pages_stat_array racing with memory offline") Signed-off-by: Haiyue Wang <haiyue.wang@intel.com> --- mm/migrate.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)