linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
To: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Tony Luck <tony.luck@intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Naoya Horiguchi <naoya.horiguchi@nec.com>
Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>,
	x86@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)),
	linux-mm@kvack.org (open list:HWPOISON MEMORY FAILURE HANDLING),
	linux-kernel@vger.kernel.org (open list:X86 ARCHITECTURE (32-BIT
	AND 64-BIT))
Subject: [PATCH 1/1] x86/mm: Forbid the zero page once it has uncorrectable errors
Date: Wed, 20 Apr 2022 17:00:09 -0400	[thread overview]
Message-ID: <20220420210009.65666-1-qiuxu.zhuo@intel.com> (raw)

Accessing to the zero page with uncorrectable errors causes unexpected
machine checks. So forbid the zero page from being used by user-space
processes once it has uncorrectable errors. Processes that have already
mapped the zero page with uncorrectable errors will get killed once they
access to it. New processes will not use the zero page.

Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
---
1) Processes that have already mapped the zero page with uncorrectable
   errors could be recovered by attaching a new zeroed anonymous page.
   But this may need to walk all page tables for all such processes to
   update the PTEs pointing to the zero page. Looks like a big modification
   for a rare problem?

2) Some validation tests that sometimes pick up the virtual address
   mapped to the zero page to inject errors get themself killed and can't
   run anymore until reboot the system. To avoid injecting errors to the
   zero page, please refer to the path:

   https://lore.kernel.org/all/20220419211921.2230752-1-tony.luck@intel.com/

 arch/x86/include/asm/pgtable.h | 3 +++
 arch/x86/kernel/cpu/mce/core.c | 6 ++++++
 arch/x86/mm/pgtable.c          | 2 ++
 mm/memory-failure.c            | 2 +-
 4 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 62ab07e24aef..d4b8693452e5 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -55,6 +55,9 @@ extern unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)]
 	__visible;
 #define ZERO_PAGE(vaddr) ((void)(vaddr),virt_to_page(empty_zero_page))
 
+extern bool __read_mostly forbids_zeropage;
+#define mm_forbids_zeropage(x)	forbids_zeropage
+
 extern spinlock_t pgd_lock;
 extern struct list_head pgd_list;
 
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 981496e6bc0e..5b3af27cc8fa 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -44,6 +44,7 @@
 #include <linux/sync_core.h>
 #include <linux/task_work.h>
 #include <linux/hardirq.h>
+#include <linux/pgtable.h>
 
 #include <asm/intel-family.h>
 #include <asm/processor.h>
@@ -1370,6 +1371,11 @@ static void queue_task_work(struct mce *m, char *msg, void (*func)(struct callba
 	if (count > 1)
 		return;
 
+	if (is_zero_pfn(current->mce_addr >> PAGE_SHIFT) && !forbids_zeropage) {
+		pr_err("Forbid user-space process from using zero page\n");
+		forbids_zeropage = true;
+	}
+
 	task_work_add(current, &current->mce_kill_me, TWA_RESUME);
 }
 
diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
index 3481b35cb4ec..c0c56bce3acc 100644
--- a/arch/x86/mm/pgtable.c
+++ b/arch/x86/mm/pgtable.c
@@ -28,6 +28,8 @@ void paravirt_tlb_remove_table(struct mmu_gather *tlb, void *table)
 
 gfp_t __userpte_alloc_gfp = GFP_PGTABLE_USER | PGTABLE_HIGHMEM;
 
+bool __read_mostly forbids_zeropage;
+
 pgtable_t pte_alloc_one(struct mm_struct *mm)
 {
 	return __pte_alloc_one(mm, __userpte_alloc_gfp);
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index dcb6bb9cf731..30ad7bdeb89f 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1744,7 +1744,7 @@ int memory_failure(unsigned long pfn, int flags)
 		goto unlock_mutex;
 	}
 
-	if (TestSetPageHWPoison(p)) {
+	if (TestSetPageHWPoison(p) || is_zero_pfn(pfn)) {
 		pr_err("Memory failure: %#lx: already hardware poisoned\n",
 			pfn);
 		res = -EHWPOISON;
-- 
2.17.1



             reply	other threads:[~2022-04-20 13:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20 21:00 Qiuxu Zhuo [this message]
2022-04-20 13:39 ` Dave Hansen
2022-04-21  7:53   ` Zhuo, Qiuxu
2022-04-21  8:50     ` David Hildenbrand

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=20220420210009.65666-1-qiuxu.zhuo@intel.com \
    --to=qiuxu.zhuo@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=naoya.horiguchi@nec.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /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