Re: [RESEND PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page
> Reviewed-by: Naoya Horiguchi > Signed-off-by: Wanpeng Li Acked-by: Andi Kleen -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page
Changelog:
*v1 -> v2: reverse PageTransHuge(page) && !PageHuge(page) check
PageTransHuge() can't guarantee the page is transparent huge page since it
return true for both transparent huge and hugetlbfs pages. This patch fix
it by check the page is also !hugetlbfs page.
Before patch:
[ 121.571128] Injecting memory failure at pfn 23a200
[ 121.571141] MCE 0x23a200: huge page recovery: Delayed
[ 140.355100] MCE: Memory failure is now running on 0x23a200
After patch:
[ 94.290793] Injecting memory failure at pfn 23a000
[ 94.290800] MCE 0x23a000: huge page recovery: Delayed
[ 105.722303] MCE: Software-unpoisoned page 0x23a000
Reviewed-by: Naoya Horiguchi
Signed-off-by: Wanpeng Li
---
mm/memory-failure.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index e28ee77..b114570 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
* worked by memory_failure() and the page lock is not held yet.
* In such case, we yield to memory_failure() and make unpoison fail.
*/
- if (PageTransHuge(page)) {
+ if (!PageHuge(page) && PageTransHuge(page)) {
pr_info("MCE: Memory failure is now running on %#lx\n", pfn);
return 0;
}
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page
Changelog:
*v1 - v2: reverse PageTransHuge(page) !PageHuge(page) check
PageTransHuge() can't guarantee the page is transparent huge page since it
return true for both transparent huge and hugetlbfs pages. This patch fix
it by check the page is also !hugetlbfs page.
Before patch:
[ 121.571128] Injecting memory failure at pfn 23a200
[ 121.571141] MCE 0x23a200: huge page recovery: Delayed
[ 140.355100] MCE: Memory failure is now running on 0x23a200
After patch:
[ 94.290793] Injecting memory failure at pfn 23a000
[ 94.290800] MCE 0x23a000: huge page recovery: Delayed
[ 105.722303] MCE: Software-unpoisoned page 0x23a000
Reviewed-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
mm/memory-failure.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index e28ee77..b114570 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
* worked by memory_failure() and the page lock is not held yet.
* In such case, we yield to memory_failure() and make unpoison fail.
*/
- if (PageTransHuge(page)) {
+ if (!PageHuge(page) PageTransHuge(page)) {
pr_info(MCE: Memory failure is now running on %#lx\n, pfn);
return 0;
}
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page
Reviewed-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com Acked-by: Andi Kleen a...@linux.intel.com -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page
On Tue, Sep 03, 2013 at 12:18:58PM +0800, Wanpeng Li wrote:
> Date: Tue, 3 Sep 2013 12:18:58 +0800
> From: Wanpeng Li
> To: Chen Gong
> Cc: Andrew Morton , Andi Kleen
> , Fengguang Wu , Naoya
> Horiguchi , Tony Luck ,
> linux...@kvack.org, linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge
> page
> User-Agent: Mutt/1.5.21 (2010-09-15)
>
> On Mon, Sep 02, 2013 at 11:15:19PM -0400, Chen Gong wrote:
> >On Tue, Sep 03, 2013 at 07:36:44AM +0800, Wanpeng Li wrote:
> >> Date: Tue, 3 Sep 2013 07:36:44 +0800
> >> From: Wanpeng Li
> >> To: Andrew Morton
> >> Cc: Andi Kleen , Fengguang Wu
> >> , Naoya Horiguchi ,
> >> Tony Luck , gong.c...@linux.intel.com,
> >> linux...@kvack.org, linux-kernel@vger.kernel.org, Wanpeng Li
> >>
> >> Subject: [PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page
> >> X-Mailer: git-send-email 1.7.5.4
> >>
> >> Changelog:
> >> *v1 -> v2: reverse PageTransHuge(page) && !PageHuge(page) check
> >>
> >> PageTransHuge() can't guarantee the page is transparent huge page since it
> >> return true for both transparent huge and hugetlbfs pages. This patch fix
> >> it by check the page is also !hugetlbfs page.
> >>
> >> Before patch:
> >>
> >> [ 121.571128] Injecting memory failure at pfn 23a200
> >> [ 121.571141] MCE 0x23a200: huge page recovery: Delayed
> >> [ 140.355100] MCE: Memory failure is now running on 0x23a200
> >>
> >> After patch:
> >>
> >> [ 94.290793] Injecting memory failure at pfn 23a000
> >> [ 94.290800] MCE 0x23a000: huge page recovery: Delayed
> >> [ 105.722303] MCE: Software-unpoisoned page 0x23a000
> >>
> >> Signed-off-by: Wanpeng Li
> >> ---
> >> mm/memory-failure.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> >> index e28ee77..b114570 100644
> >> --- a/mm/memory-failure.c
> >> +++ b/mm/memory-failure.c
> >> @@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
> >> * worked by memory_failure() and the page lock is not held yet.
> >> * In such case, we yield to memory_failure() and make unpoison fail.
> >> */
> >> - if (PageTransHuge(page)) {
> >> + if (!PageHuge(page) && PageTransHuge(page)) {
> >>pr_info("MCE: Memory failure is now running on %#lx\n", pfn);
> >>return 0;
> >>}
> >
> >Not sure which git tree should be used to apply this patch series? I assume
> >this patch series follows this link: https://lkml.org/lkml/2013/8/26/76.
> >
>
> mmotm tree or linux-next. ;-)
>
> >In unpoison_memory we already have
> >if (PageHuge(page)) {
> >...
> >return 0;
> >}
> >so it looks like this patch is redundant.
>
> - Do you aware there is condition before go to this check?
> - Do you also analysis why the check can't catch the hugetlbfs page
> through the dump information?
>
Looks like we use different trees. After checking your working tree,
your patch is right. So just ignore my words above. FWIW, please be
polite and give a positive response.
> Regards,
> Wanpeng Li
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
signature.asc
Description: Digital signature
Re: [PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page
On Tue, Sep 03, 2013 at 12:18:58PM +0800, Wanpeng Li wrote:
Date: Tue, 3 Sep 2013 12:18:58 +0800
From: Wanpeng Li liw...@linux.vnet.ibm.com
To: Chen Gong gong.c...@linux.intel.com
Cc: Andrew Morton a...@linux-foundation.org, Andi Kleen
a...@firstfloor.org, Fengguang Wu fengguang...@intel.com, Naoya
Horiguchi n-horigu...@ah.jp.nec.com, Tony Luck tony.l...@intel.com,
linux...@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge
page
User-Agent: Mutt/1.5.21 (2010-09-15)
On Mon, Sep 02, 2013 at 11:15:19PM -0400, Chen Gong wrote:
On Tue, Sep 03, 2013 at 07:36:44AM +0800, Wanpeng Li wrote:
Date: Tue, 3 Sep 2013 07:36:44 +0800
From: Wanpeng Li liw...@linux.vnet.ibm.com
To: Andrew Morton a...@linux-foundation.org
Cc: Andi Kleen a...@firstfloor.org, Fengguang Wu
fengguang...@intel.com, Naoya Horiguchi n-horigu...@ah.jp.nec.com,
Tony Luck tony.l...@intel.com, gong.c...@linux.intel.com,
linux...@kvack.org, linux-kernel@vger.kernel.org, Wanpeng Li
liw...@linux.vnet.ibm.com
Subject: [PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page
X-Mailer: git-send-email 1.7.5.4
Changelog:
*v1 - v2: reverse PageTransHuge(page) !PageHuge(page) check
PageTransHuge() can't guarantee the page is transparent huge page since it
return true for both transparent huge and hugetlbfs pages. This patch fix
it by check the page is also !hugetlbfs page.
Before patch:
[ 121.571128] Injecting memory failure at pfn 23a200
[ 121.571141] MCE 0x23a200: huge page recovery: Delayed
[ 140.355100] MCE: Memory failure is now running on 0x23a200
After patch:
[ 94.290793] Injecting memory failure at pfn 23a000
[ 94.290800] MCE 0x23a000: huge page recovery: Delayed
[ 105.722303] MCE: Software-unpoisoned page 0x23a000
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
mm/memory-failure.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index e28ee77..b114570 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
* worked by memory_failure() and the page lock is not held yet.
* In such case, we yield to memory_failure() and make unpoison fail.
*/
- if (PageTransHuge(page)) {
+ if (!PageHuge(page) PageTransHuge(page)) {
pr_info(MCE: Memory failure is now running on %#lx\n, pfn);
return 0;
}
Not sure which git tree should be used to apply this patch series? I assume
this patch series follows this link: https://lkml.org/lkml/2013/8/26/76.
mmotm tree or linux-next. ;-)
In unpoison_memory we already have
if (PageHuge(page)) {
...
return 0;
}
so it looks like this patch is redundant.
- Do you aware there is condition before go to this check?
- Do you also analysis why the check can't catch the hugetlbfs page
through the dump information?
Looks like we use different trees. After checking your working tree,
your patch is right. So just ignore my words above. FWIW, please be
polite and give a positive response.
Regards,
Wanpeng Li
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a
signature.asc
Description: Digital signature
Re: [PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page
On Tue, Sep 03, 2013 at 07:36:44AM +0800, Wanpeng Li wrote:
> Date: Tue, 3 Sep 2013 07:36:44 +0800
> From: Wanpeng Li
> To: Andrew Morton
> Cc: Andi Kleen , Fengguang Wu
> , Naoya Horiguchi ,
> Tony Luck , gong.c...@linux.intel.com,
> linux...@kvack.org, linux-kernel@vger.kernel.org, Wanpeng Li
>
> Subject: [PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page
> X-Mailer: git-send-email 1.7.5.4
>
> Changelog:
> *v1 -> v2: reverse PageTransHuge(page) && !PageHuge(page) check
>
> PageTransHuge() can't guarantee the page is transparent huge page since it
> return true for both transparent huge and hugetlbfs pages. This patch fix
> it by check the page is also !hugetlbfs page.
>
> Before patch:
>
> [ 121.571128] Injecting memory failure at pfn 23a200
> [ 121.571141] MCE 0x23a200: huge page recovery: Delayed
> [ 140.355100] MCE: Memory failure is now running on 0x23a200
>
> After patch:
>
> [ 94.290793] Injecting memory failure at pfn 23a000
> [ 94.290800] MCE 0x23a000: huge page recovery: Delayed
> [ 105.722303] MCE: Software-unpoisoned page 0x23a000
>
> Signed-off-by: Wanpeng Li
> ---
> mm/memory-failure.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index e28ee77..b114570 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
>* worked by memory_failure() and the page lock is not held yet.
>* In such case, we yield to memory_failure() and make unpoison fail.
>*/
> - if (PageTransHuge(page)) {
> + if (!PageHuge(page) && PageTransHuge(page)) {
> pr_info("MCE: Memory failure is now running on %#lx\n", pfn);
> return 0;
> }
Not sure which git tree should be used to apply this patch series? I assume
this patch series follows this link: https://lkml.org/lkml/2013/8/26/76.
In unpoison_memory we already have
if (PageHuge(page)) {
...
return 0;
}
so it looks like this patch is redundant.
signature.asc
Description: Digital signature
Re: [PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page
On Tue, Sep 03, 2013 at 07:36:44AM +0800, Wanpeng Li wrote:
> Changelog:
> *v1 -> v2: reverse PageTransHuge(page) && !PageHuge(page) check
>
> PageTransHuge() can't guarantee the page is transparent huge page since it
> return true for both transparent huge and hugetlbfs pages. This patch fix
> it by check the page is also !hugetlbfs page.
>
> Before patch:
>
> [ 121.571128] Injecting memory failure at pfn 23a200
> [ 121.571141] MCE 0x23a200: huge page recovery: Delayed
> [ 140.355100] MCE: Memory failure is now running on 0x23a200
>
> After patch:
>
> [ 94.290793] Injecting memory failure at pfn 23a000
> [ 94.290800] MCE 0x23a000: huge page recovery: Delayed
> [ 105.722303] MCE: Software-unpoisoned page 0x23a000
>
> Signed-off-by: Wanpeng Li
Thanks!
Reviewed-by: Naoya Horiguchi
> ---
> mm/memory-failure.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index e28ee77..b114570 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
>* worked by memory_failure() and the page lock is not held yet.
>* In such case, we yield to memory_failure() and make unpoison fail.
>*/
> - if (PageTransHuge(page)) {
> + if (!PageHuge(page) && PageTransHuge(page)) {
> pr_info("MCE: Memory failure is now running on %#lx\n", pfn);
> return 0;
> }
> --
> 1.8.1.2
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page
Changelog:
*v1 -> v2: reverse PageTransHuge(page) && !PageHuge(page) check
PageTransHuge() can't guarantee the page is transparent huge page since it
return true for both transparent huge and hugetlbfs pages. This patch fix
it by check the page is also !hugetlbfs page.
Before patch:
[ 121.571128] Injecting memory failure at pfn 23a200
[ 121.571141] MCE 0x23a200: huge page recovery: Delayed
[ 140.355100] MCE: Memory failure is now running on 0x23a200
After patch:
[ 94.290793] Injecting memory failure at pfn 23a000
[ 94.290800] MCE 0x23a000: huge page recovery: Delayed
[ 105.722303] MCE: Software-unpoisoned page 0x23a000
Signed-off-by: Wanpeng Li
---
mm/memory-failure.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index e28ee77..b114570 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
* worked by memory_failure() and the page lock is not held yet.
* In such case, we yield to memory_failure() and make unpoison fail.
*/
- if (PageTransHuge(page)) {
+ if (!PageHuge(page) && PageTransHuge(page)) {
pr_info("MCE: Memory failure is now running on %#lx\n", pfn);
return 0;
}
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page
Changelog:
*v1 - v2: reverse PageTransHuge(page) !PageHuge(page) check
PageTransHuge() can't guarantee the page is transparent huge page since it
return true for both transparent huge and hugetlbfs pages. This patch fix
it by check the page is also !hugetlbfs page.
Before patch:
[ 121.571128] Injecting memory failure at pfn 23a200
[ 121.571141] MCE 0x23a200: huge page recovery: Delayed
[ 140.355100] MCE: Memory failure is now running on 0x23a200
After patch:
[ 94.290793] Injecting memory failure at pfn 23a000
[ 94.290800] MCE 0x23a000: huge page recovery: Delayed
[ 105.722303] MCE: Software-unpoisoned page 0x23a000
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
mm/memory-failure.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index e28ee77..b114570 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
* worked by memory_failure() and the page lock is not held yet.
* In such case, we yield to memory_failure() and make unpoison fail.
*/
- if (PageTransHuge(page)) {
+ if (!PageHuge(page) PageTransHuge(page)) {
pr_info(MCE: Memory failure is now running on %#lx\n, pfn);
return 0;
}
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page
On Tue, Sep 03, 2013 at 07:36:44AM +0800, Wanpeng Li wrote:
Changelog:
*v1 - v2: reverse PageTransHuge(page) !PageHuge(page) check
PageTransHuge() can't guarantee the page is transparent huge page since it
return true for both transparent huge and hugetlbfs pages. This patch fix
it by check the page is also !hugetlbfs page.
Before patch:
[ 121.571128] Injecting memory failure at pfn 23a200
[ 121.571141] MCE 0x23a200: huge page recovery: Delayed
[ 140.355100] MCE: Memory failure is now running on 0x23a200
After patch:
[ 94.290793] Injecting memory failure at pfn 23a000
[ 94.290800] MCE 0x23a000: huge page recovery: Delayed
[ 105.722303] MCE: Software-unpoisoned page 0x23a000
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
Thanks!
Reviewed-by: Naoya Horiguchi n-horigu...@ah.jp.nec.com
---
mm/memory-failure.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index e28ee77..b114570 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
* worked by memory_failure() and the page lock is not held yet.
* In such case, we yield to memory_failure() and make unpoison fail.
*/
- if (PageTransHuge(page)) {
+ if (!PageHuge(page) PageTransHuge(page)) {
pr_info(MCE: Memory failure is now running on %#lx\n, pfn);
return 0;
}
--
1.8.1.2
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: a href=mailto:d...@kvack.org; em...@kvack.org /a
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page
On Tue, Sep 03, 2013 at 07:36:44AM +0800, Wanpeng Li wrote:
Date: Tue, 3 Sep 2013 07:36:44 +0800
From: Wanpeng Li liw...@linux.vnet.ibm.com
To: Andrew Morton a...@linux-foundation.org
Cc: Andi Kleen a...@firstfloor.org, Fengguang Wu
fengguang...@intel.com, Naoya Horiguchi n-horigu...@ah.jp.nec.com,
Tony Luck tony.l...@intel.com, gong.c...@linux.intel.com,
linux...@kvack.org, linux-kernel@vger.kernel.org, Wanpeng Li
liw...@linux.vnet.ibm.com
Subject: [PATCH v2 2/4] mm/hwpoison: fix miss catch transparent huge page
X-Mailer: git-send-email 1.7.5.4
Changelog:
*v1 - v2: reverse PageTransHuge(page) !PageHuge(page) check
PageTransHuge() can't guarantee the page is transparent huge page since it
return true for both transparent huge and hugetlbfs pages. This patch fix
it by check the page is also !hugetlbfs page.
Before patch:
[ 121.571128] Injecting memory failure at pfn 23a200
[ 121.571141] MCE 0x23a200: huge page recovery: Delayed
[ 140.355100] MCE: Memory failure is now running on 0x23a200
After patch:
[ 94.290793] Injecting memory failure at pfn 23a000
[ 94.290800] MCE 0x23a000: huge page recovery: Delayed
[ 105.722303] MCE: Software-unpoisoned page 0x23a000
Signed-off-by: Wanpeng Li liw...@linux.vnet.ibm.com
---
mm/memory-failure.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index e28ee77..b114570 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1349,7 +1349,7 @@ int unpoison_memory(unsigned long pfn)
* worked by memory_failure() and the page lock is not held yet.
* In such case, we yield to memory_failure() and make unpoison fail.
*/
- if (PageTransHuge(page)) {
+ if (!PageHuge(page) PageTransHuge(page)) {
pr_info(MCE: Memory failure is now running on %#lx\n, pfn);
return 0;
}
Not sure which git tree should be used to apply this patch series? I assume
this patch series follows this link: https://lkml.org/lkml/2013/8/26/76.
In unpoison_memory we already have
if (PageHuge(page)) {
...
return 0;
}
so it looks like this patch is redundant.
signature.asc
Description: Digital signature
