All of lore.kernel.org
 help / color / mirror / Atom feed
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>

       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: link
Be 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.