From: "Hillf Danton" <hillf.zj@alibaba-inc.com> To: "Michal Hocko" <mhocko@suse.com> Cc: "'zhongjiang'" <zhongjiang@huawei.com>, "linux-kernel" <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>, "Andrew Morton" <akpm@linux-foundation.org> Subject: Re: + mm-hugetlb-fix-race-when-migrate-pages.patch added to -mm tree Date: Thu, 21 Jul 2016 16:19:42 +0800 [thread overview] Message-ID: <003801d1e328$a24c2030$e6e46090$@alibaba-inc.com> (raw) In-Reply-To: <003701d1e328$202ca9d0$6085fd70$@alibaba-inc.com> > > From b1e9b3214f1859fdf7d134cdcb56f5871933539c Mon Sep 17 00:00:00 2001 > From: Michal Hocko <mhocko@suse.com> > Date: Thu, 21 Jul 2016 09:28:13 +0200 > Subject: [PATCH] mm, hugetlb: fix huge_pte_alloc BUG_ON > > Zhong Jiang has reported a BUG_ON from huge_pte_alloc hitting when he > runs his database load with memory online and offline running in > parallel. The reason is that huge_pmd_share might detect a shared pmd > which is currently migrated and so it has migration pte which is > !pte_huge. > > There doesn't seem to be any easy way to prevent from the race and in > fact seeing the migration swap entry is not harmful. Both callers of > huge_pte_alloc are prepared to handle them. copy_hugetlb_page_range > will copy the swap entry and make it COW if needed. hugetlb_fault will > back off and so the page fault is retries if the page is still under > migration and waits for its completion in hugetlb_fault. > > That means that the BUG_ON is wrong and we should update it. Let's > simply check that all present ptes are pte_huge instead. > > Reported-by: zhongjiang <zhongjiang@huawei.com> > Signed-off-by: Michal Hocko <mhocko@suse.com> > --- Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com> > mm/hugetlb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index 34379d653aa3..31dd2b8b86b3 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -4303,7 +4303,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, > pte = (pte_t *)pmd_alloc(mm, pud, addr); > } > } > - BUG_ON(pte && !pte_none(*pte) && !pte_huge(*pte)); > + BUG_ON(pte && pte_present(*pte) && !pte_huge(*pte)); > > return pte; > } > -- > 2.8.1 >
WARNING: multiple messages have this Message-ID (diff)
From: "Hillf Danton" <hillf.zj@alibaba-inc.com> To: Michal Hocko <mhocko@suse.com> Cc: 'zhongjiang' <zhongjiang@huawei.com>, linux-kernel <linux-kernel@vger.kernel.org>, linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org> Subject: Re: + mm-hugetlb-fix-race-when-migrate-pages.patch added to -mm tree Date: Thu, 21 Jul 2016 16:19:42 +0800 [thread overview] Message-ID: <003801d1e328$a24c2030$e6e46090$@alibaba-inc.com> (raw) In-Reply-To: <003701d1e328$202ca9d0$6085fd70$@alibaba-inc.com> > > From b1e9b3214f1859fdf7d134cdcb56f5871933539c Mon Sep 17 00:00:00 2001 > From: Michal Hocko <mhocko@suse.com> > Date: Thu, 21 Jul 2016 09:28:13 +0200 > Subject: [PATCH] mm, hugetlb: fix huge_pte_alloc BUG_ON > > Zhong Jiang has reported a BUG_ON from huge_pte_alloc hitting when he > runs his database load with memory online and offline running in > parallel. The reason is that huge_pmd_share might detect a shared pmd > which is currently migrated and so it has migration pte which is > !pte_huge. > > There doesn't seem to be any easy way to prevent from the race and in > fact seeing the migration swap entry is not harmful. Both callers of > huge_pte_alloc are prepared to handle them. copy_hugetlb_page_range > will copy the swap entry and make it COW if needed. hugetlb_fault will > back off and so the page fault is retries if the page is still under > migration and waits for its completion in hugetlb_fault. > > That means that the BUG_ON is wrong and we should update it. Let's > simply check that all present ptes are pte_huge instead. > > Reported-by: zhongjiang <zhongjiang@huawei.com> > Signed-off-by: Michal Hocko <mhocko@suse.com> > --- Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com> > mm/hugetlb.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index 34379d653aa3..31dd2b8b86b3 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -4303,7 +4303,7 @@ pte_t *huge_pte_alloc(struct mm_struct *mm, > pte = (pte_t *)pmd_alloc(mm, pud, addr); > } > } > - BUG_ON(pte && !pte_none(*pte) && !pte_huge(*pte)); > + BUG_ON(pte && pte_present(*pte) && !pte_huge(*pte)); > > return pte; > } > -- > 2.8.1 > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next parent reply other threads:[~2016-07-21 8:20 UTC|newest] Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <003701d1e328$202ca9d0$6085fd70$@alibaba-inc.com> 2016-07-21 8:19 ` Hillf Danton [this message] 2016-07-21 8:19 ` + mm-hugetlb-fix-race-when-migrate-pages.patch added to -mm tree Hillf Danton 2016-07-19 23:06 akpm 2016-07-21 7:43 ` Michal Hocko 2016-07-21 8:13 ` Naoya Horiguchi 2016-07-21 10:29 ` Michal Hocko 2016-07-21 10:54 ` zhong jiang 2016-07-21 11:27 ` Michal Hocko 2016-07-21 12:14 ` zhong jiang 2016-07-21 12:30 ` Michal Hocko 2016-07-21 12:45 ` zhong jiang 2016-07-21 12:55 ` Michal Hocko 2016-07-21 13:25 ` zhong jiang 2016-07-21 13:40 ` Michal Hocko 2016-07-21 13:58 ` zhong jiang 2016-07-21 14:01 ` Michal Hocko 2016-07-21 14:13 ` zhong jiang 2016-07-21 14:27 ` Michal Hocko 2016-07-21 14:33 ` zhong jiang 2016-07-22 7:17 ` Naoya Horiguchi 2016-07-26 7:58 ` Michal Hocko 2016-07-26 14:04 ` zhong jiang 2016-07-27 14:44 ` Michal Hocko 2016-07-29 11:27 ` Michal Hocko 2016-07-30 6:33 ` zhong jiang 2016-08-01 11:02 ` Michal Hocko 2016-08-01 15:04 ` zhong jiang 2016-08-01 15:31 ` Michal Hocko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='003801d1e328$a24c2030$e6e46090$@alibaba-inc.com' \ --to=hillf.zj@alibaba-inc.com \ --cc=akpm@linux-foundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@suse.com \ --cc=zhongjiang@huawei.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.