From: zhong jiang <zhongjiang@huawei.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: vbabka@suse.cz, qiuxishi@huawei.com, akpm@linux-foundation.org,
linux-mm@kvack.org, Mike Kravetz <mike.kravetz@oracle.com>,
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Subject: Re: [PATCH v2] mm/hugetlb: fix race when migrate pages
Date: Wed, 20 Jul 2016 18:03:40 +0800 [thread overview]
Message-ID: <578F4C7C.6000706@huawei.com> (raw)
In-Reply-To: <20160720073859.GE11249@dhcp22.suse.cz>
On 2016/7/20 15:38, Michal Hocko wrote:
> [CC Mike and Naoya]
> On Tue 19-07-16 21:45:58, zhongjiang wrote:
>> From: zhong jiang <zhongjiang@huawei.com>
>>
>> I hit the following code in huge_pte_alloc when run the database and
>> online-offline memory in the system.
>>
>> BUG_ON(pte && !pte_none(*pte) && !pte_huge(*pte));
>>
>> when pmd share function enable, we may be obtain a shared pmd entry.
>> due to ongoing offline memory , the pmd entry points to the page will
>> turn into migrate condition. therefore, the bug will come up.
>>
>> The patch fix it by checking the pmd entry when we obtain the lock.
>> if the shared pmd entry points to page is under migration. we should
>> allocate a new pmd entry.
> I am still not 100% sure this is correct. Does huge_pte_lockptr work
> properly for the migration swapentry? If yes and we populate the pud
> with a migration entry then is it really bad/harmful (other than hitting
> the BUG_ON which might be update to handle that case)? This might be a
> stupid question, sorry about that, but I have really problem to grasp
> the whole issue properly and the changelog didn't help me much. I would
> really appreciate some clarification here. The pmd sharing code is clear
> as mud and adding new tweaks there doesn't sound like it would make it
> more clear.
ok, Maybe the following explain will better.
cpu0 cpu1
try_to_unmap_one huge_pmd_share
page_check_address huge_pte_lockptr
spin_lock
(page entry can be set to migrate or
Posion )
pte_unmap_unlock
spin_lock
(page entry have changed)
> Also is the hwpoison check really needed?
Yes, page can be posion before spin_lock in try_to_unmap_one, so we can see that
it will also set page entry to hwpoison entry if PageHWPoison(page) is true.
>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>> ---
>> mm/hugetlb.c | 9 ++++++++-
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
>> index 6384dfd..797db55 100644
>> --- a/mm/hugetlb.c
>> +++ b/mm/hugetlb.c
>> @@ -4213,7 +4213,7 @@ pte_t *huge_pmd_share(struct mm_struct *mm, unsigned long addr, pud_t *pud)
>> struct vm_area_struct *svma;
>> unsigned long saddr;
>> pte_t *spte = NULL;
>> - pte_t *pte;
>> + pte_t *pte, entry;
>> spinlock_t *ptl;
>>
>> if (!vma_shareable(vma, addr))
>> @@ -4240,6 +4240,11 @@ pte_t *huge_pmd_share(struct mm_struct *mm, unsigned long addr, pud_t *pud)
>>
>> ptl = huge_pte_lockptr(hstate_vma(vma), mm, spte);
>> spin_lock(ptl);
>> + entry = huge_ptep_get(spte);
>> + if (is_hugetlb_entry_migration(entry) ||
>> + is_hugetlb_entry_hwpoisoned(entry)) {
>> + goto out_unlock;
>> + }
>> if (pud_none(*pud)) {
>> pud_populate(mm, pud,
>> (pmd_t *)((unsigned long)spte & PAGE_MASK));
>> @@ -4247,6 +4252,8 @@ pte_t *huge_pmd_share(struct mm_struct *mm, unsigned long addr, pud_t *pud)
>> put_page(virt_to_page(spte));
>> mm_dec_nr_pmds(mm);
>> }
>> +
>> +out_unlock:
>> spin_unlock(ptl);
>> out:
>> pte = (pte_t *)pmd_alloc(mm, pud, addr);
>> --
>> 1.8.3.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 prev parent reply other threads:[~2016-07-20 10:11 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-19 13:45 [PATCH v2] mm/hugetlb: fix race when migrate pages zhongjiang
2016-07-20 7:38 ` Michal Hocko
2016-07-20 10:03 ` zhong jiang [this message]
2016-07-20 12:16 ` Michal Hocko
2016-07-20 12:45 ` Michal Hocko
2016-07-20 13:00 ` Michal Hocko
2016-07-20 13:24 ` Michal Hocko
2016-07-21 9:25 ` zhong jiang
-- strict thread matches above, loose matches on Subject: below --
2016-07-19 13:04 zhongjiang
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=578F4C7C.6000706@huawei.com \
--to=zhongjiang@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.cz \
--cc=mike.kravetz@oracle.com \
--cc=n-horiguchi@ah.jp.nec.com \
--cc=qiuxishi@huawei.com \
--cc=vbabka@suse.cz \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).