[PATCH] x86/mm, mm/hwpoison: fix unmap kernel 1:1 pages

[PATCH] x86/mm, mm/hwpoison: fix unmap kernel 1:1 pages

[luofei]

Only unmap the page when the memory error is properly handled
by calling memory_failure(), not the other way around.

Fixes: 26f8c38bb466("x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages")

Signed-off-by: luofei <luofei@unicloud.com>
Cc: stable@vger.kernel.org #v4.14
---
 arch/x86/kernel/cpu/mcheck/mce.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index 95c09db1bba2..d8399a689165 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -589,7 +589,7 @@ static int srao_decode_notifier(struct notifier_block *nb, unsigned long val,
 
 	if (mce_usable_address(mce) && (mce->severity == MCE_AO_SEVERITY)) {
 		pfn = mce->addr >> PAGE_SHIFT;
-		if (memory_failure(pfn, MCE_VECTOR, 0))
+		if (!memory_failure(pfn, MCE_VECTOR, 0))
 			mce_unmap_kpfn(pfn);
 	}
 
-- 
2.27.0

Re: [PATCH] x86/mm, mm/hwpoison: fix unmap kernel 1:1 pages

[Greg KH]

On Mon, Feb 07, 2022 at 02:52:42AM -0500, luofei wrote:
> Only unmap the page when the memory error is properly handled
> by calling memory_failure(), not the other way around.
> 
> Fixes: 26f8c38bb466("x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages")

This commit is not in Linus's tree.  Please use the correct commit id.

thanks,

greg k-h

Re: [PATCH] x86/mm, mm/hwpoison: fix unmap kernel 1:1 pages

[Borislav Petkov]

On Mon, Feb 07, 2022 at 09:14:23AM +0100, Greg KH wrote:
> On Mon, Feb 07, 2022 at 02:52:42AM -0500, luofei wrote:
> > Only unmap the page when the memory error is properly handled
> > by calling memory_failure(), not the other way around.
> > 
> > Fixes: 26f8c38bb466("x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages")
> 
> This commit is not in Linus's tree.  Please use the correct commit id.

I think he's trying to fix the backport:

see 26f8c38bb466c1a2d232d7609fb4bfb4bc121678 which is the stable tree backport:

@@ -582,7 +586,8 @@ static int srao_decode_notifier(struct notifier_block *nb, unsigned long val,
 
        if (mce_usable_address(mce) && (mce->severity == MCE_AO_SEVERITY)) {
                pfn = mce->addr >> PAGE_SHIFT;
-               memory_failure(pfn, MCE_VECTOR, 0);
+               if (memory_failure(pfn, MCE_VECTOR, 0))
+                       mce_unmap_kpfn(pfn);
        }


vs the upstream commit:

fd0e786d9d09024f67bd71ec094b110237dc3840

@@ -590,7 +594,8 @@ static int srao_decode_notifier(struct notifier_block *nb, unsigned long val,
 
        if (mce_usable_address(mce) && (mce->severity == MCE_AO_SEVERITY)) {
                pfn = mce->addr >> PAGE_SHIFT;
-               memory_failure(pfn, 0);
+               if (!memory_failure(pfn, 0))
+                       mce_unmap_kpfn(pfn);
        }
 
        return NOTIFY_OK;

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] x86/mm, mm/hwpoison: fix unmap kernel 1:1 pages

[Greg KH]

On Mon, Feb 07, 2022 at 10:35:41AM +0100, Borislav Petkov wrote:
> On Mon, Feb 07, 2022 at 09:14:23AM +0100, Greg KH wrote:
> > On Mon, Feb 07, 2022 at 02:52:42AM -0500, luofei wrote:
> > > Only unmap the page when the memory error is properly handled
> > > by calling memory_failure(), not the other way around.
> > > 
> > > Fixes: 26f8c38bb466("x86/mm, mm/hwpoison: Don't unconditionally unmap kernel 1:1 pages")
> > 
> > This commit is not in Linus's tree.  Please use the correct commit id.
> 
> I think he's trying to fix the backport:
> 
> see 26f8c38bb466c1a2d232d7609fb4bfb4bc121678 which is the stable tree backport:
> 
> @@ -582,7 +586,8 @@ static int srao_decode_notifier(struct notifier_block *nb, unsigned long val,
>  
>         if (mce_usable_address(mce) && (mce->severity == MCE_AO_SEVERITY)) {
>                 pfn = mce->addr >> PAGE_SHIFT;
> -               memory_failure(pfn, MCE_VECTOR, 0);
> +               if (memory_failure(pfn, MCE_VECTOR, 0))
> +                       mce_unmap_kpfn(pfn);
>         }
> 
> 
> vs the upstream commit:
> 
> fd0e786d9d09024f67bd71ec094b110237dc3840
> 
> @@ -590,7 +594,8 @@ static int srao_decode_notifier(struct notifier_block *nb, unsigned long val,
>  
>         if (mce_usable_address(mce) && (mce->severity == MCE_AO_SEVERITY)) {
>                 pfn = mce->addr >> PAGE_SHIFT;
> -               memory_failure(pfn, 0);
> +               if (!memory_failure(pfn, 0))
> +                       mce_unmap_kpfn(pfn);
>         }
>  
>         return NOTIFY_OK;
> 

Ah, ok, if so, this needs to be documented really really well in the
changelog text so no one is confused.  Like me :)

thanks,

greg k-h

Re: 答复: [PATCH] x86/mm, mm/hwpoison: fix unmap kernel 1:1 pages

[Greg KH]

On Mon, Feb 07, 2022 at 10:03:29AM +0000, 罗飞 wrote:
> >I think he's trying to fix the backport:
> >
> >see 26f8c38bb466c1a2d232d7609fb4bfb4bc121678 which is the stable tree backport:
> >
> >@@ -582,7 +586,8 @@ static int srao_decode_notifier(struct notifier_block *nb, unsigned long val,
> >
> >       if (mce_usable_address(mce) && (mce->severity == MCE_AO_SEVERITY)) {
> >               pfn = mce->addr >> PAGE_SHIFT;
> >-               memory_failure(pfn, MCE_VECTOR, 0);
> >+               if (memory_failure(pfn, MCE_VECTOR, 0))
> >+                       mce_unmap_kpfn(pfn);
>  >       }
> >
> >
> >vs the upstream commit:
> >
> >fd0e786d9d09024f67bd71ec094b110237dc3840
> >
> >@@ -590,7 +594,8 @@ static int srao_decode_notifier(struct notifier_block *nb, unsigned long val,
> >
> >        if (mce_usable_address(mce) && (mce->severity == MCE_AO_SEVERITY)) {
> >               pfn = mce->addr >> PAGE_SHIFT;
> >-               memory_failure(pfn, 0);
> >+               if (!memory_failure(pfn, 0))
> >+                       mce_unmap_kpfn(pfn);
> >       }
> >
> >        return NOTIFY_OK;
> 
> 
> Sorry for my not familiar with submitting patches to stable kernel tree, and here Borislav Petkov said exactly what I meant

Great, can you please resend this and document what this patch is doing
and why it is not in upstream and why is it needed only in this one
branch?

thanks,

greg k-h