include/linux/highmem.h | 24 ++++++++++++++++++++++++ include/linux/mm.h | 5 ++++- mm/memory.c | 32 ++++++++++++++++++++++---------- 3 files changed, 50 insertions(+), 11 deletions(-)
Part 1 deals with the process that triggered the copy on write fault with a store to a shared read-only page. That process is send a SIGBUS with the usual machine check decoration to specify the virtual address of the lost page, together with the scope. Part 2 sets up to asynchronously take the page with the uncorrected error offline to prevent additional machine check faults. H/t to Miaohe Lin <linmiaohe@huawei.com> and Shuai Xue <xueshuai@linux.alibaba.com> for pointing me to the existing function to queue a call to memory_failure(). On x86 there is some duplicate reporting (because the error is also signalled by the memory controller as well as by the core that triggered the machine check). Console logs look like this: [ 1647.723403] mce: [Hardware Error]: Machine check events logged Machine check from kernel copy routine [ 1647.723414] MCE: Killing einj_mem_uc:3600 due to hardware memory corruption fault at 7f3309503400 x86 fault handler sends SIGBUS to child process [ 1647.735183] Memory failure: 0x905b92d: recovery action for dirty LRU page: Recovered Async call to memory_failure() from copy on write path [ 1647.748397] Memory failure: 0x905b92d: already hardware poisoned uc_decode_notifier() processes memory controller report [ 1647.761313] MCE: Killing einj_mem_uc:3599 due to hardware memory corruption fault at 7f3309503400 Parent process tries to read poisoned page. Page has been unmapped, so #PF handler sends SIGBUS Tony Luck (2): mm, hwpoison: Try to recover from copy-on write faults mm, hwpoison: When copy-on-write hits poison, take page offline include/linux/highmem.h | 24 ++++++++++++++++++++++++ include/linux/mm.h | 5 ++++- mm/memory.c | 32 ++++++++++++++++++++++---------- 3 files changed, 50 insertions(+), 11 deletions(-) -- 2.37.3
Recover from poison consumption while copying pages in the kernel for a copy-on-write fault. Changes since v3: 1) Miaohe Lin <linmiaohe@huawei.com> pointed out that a recent change by Alexander Potapenko <glider@google.com> to copy_user_highpage() added a call to kmsan_unpoison_memory(). Same is needed in my cloned copy_mc_user_highpage() ... at least in the successful case where the page was copied with no machine checks. 2) Picked up some additional Reviewed-by and Tested-by tags. Tony Luck (2): mm, hwpoison: Try to recover from copy-on write faults mm, hwpoison: When copy-on-write hits poison, take page offline include/linux/highmem.h | 26 ++++++++++++++++++++++++++ include/linux/mm.h | 5 ++++- mm/memory.c | 32 ++++++++++++++++++++++---------- 3 files changed, 52 insertions(+), 11 deletions(-) base-commit: 30a0b95b1335e12efef89dd78518ed3e4a71a763 -- 2.37.3
If the kernel is copying a page as the result of a copy-on-write
fault and runs into an uncorrectable error, Linux will crash because
it does not have recovery code for this case where poison is consumed
by the kernel.
It is easy to set up a test case. Just inject an error into a private
page, fork(2), and have the child process write to the page.
I wrapped that neatly into a test at:
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/ras-tools.git
just enable ACPI error injection and run:
# ./einj_mem-uc -f copy-on-write
Add a new copy_user_highpage_mc() function that uses copy_mc_to_kernel()
on architectures where that is available (currently x86 and powerpc).
When an error is detected during the page copy, return VM_FAULT_HWPOISON
to caller of wp_page_copy(). This propagates up the call stack. Both x86
and powerpc have code in their fault handler to deal with this code by
sending a SIGBUS to the application.
Note that this patch avoids a system crash and signals the process that
triggered the copy-on-write action. It does not take any action for the
memory error that is still in the shared page. To handle that a call to
memory_failure() is needed. But this cannot be done from wp_page_copy()
because it holds mmap_lock(). Perhaps the architecture fault handlers
can deal with this loose end in a subsequent patch?
On Intel/x86 this loose end will often be handled automatically because
the memory controller provides an additional notification of the h/w
poison in memory, the handler for this will call memory_failure(). This
isn't a 100% solution. If there are multiple errors, not all may be
logged in this way.
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Reviewed-by: Naoya Horiguchi <naoya.horiguchi@nec.com>
Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Message-Id: <20221021200120.175753-2-tony.luck@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
---
include/linux/highmem.h | 26 ++++++++++++++++++++++++++
mm/memory.c | 30 ++++++++++++++++++++----------
2 files changed, 46 insertions(+), 10 deletions(-)
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index e9912da5441b..44242268f53b 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -319,6 +319,32 @@ static inline void copy_user_highpage(struct page *to, struct page *from,
#endif
+#ifdef copy_mc_to_kernel
+static inline int copy_mc_user_highpage(struct page *to, struct page *from,
+ unsigned long vaddr, struct vm_area_struct *vma)
+{
+ unsigned long ret;
+ char *vfrom, *vto;
+
+ vfrom = kmap_local_page(from);
+ vto = kmap_local_page(to);
+ ret = copy_mc_to_kernel(vto, vfrom, PAGE_SIZE);
+ if (!ret)
+ kmsan_unpoison_memory(page_address(to), PAGE_SIZE);
+ kunmap_local(vto);
+ kunmap_local(vfrom);
+
+ return ret;
+}
+#else
+static inline int copy_mc_user_highpage(struct page *to, struct page *from,
+ unsigned long vaddr, struct vm_area_struct *vma)
+{
+ copy_user_highpage(to, from, vaddr, vma);
+ return 0;
+}
+#endif
+
#ifndef __HAVE_ARCH_COPY_HIGHPAGE
static inline void copy_highpage(struct page *to, struct page *from)
diff --git a/mm/memory.c b/mm/memory.c
index f88c351aecd4..b6056eef2f72 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2848,10 +2848,16 @@ static inline int pte_unmap_same(struct vm_fault *vmf)
return same;
}
-static inline bool __wp_page_copy_user(struct page *dst, struct page *src,
- struct vm_fault *vmf)
+/*
+ * Return:
+ * 0: copied succeeded
+ * -EHWPOISON: copy failed due to hwpoison in source page
+ * -EAGAIN: copied failed (some other reason)
+ */
+static inline int __wp_page_copy_user(struct page *dst, struct page *src,
+ struct vm_fault *vmf)
{
- bool ret;
+ int ret;
void *kaddr;
void __user *uaddr;
bool locked = false;
@@ -2860,8 +2866,9 @@ static inline bool __wp_page_copy_user(struct page *dst, struct page *src,
unsigned long addr = vmf->address;
if (likely(src)) {
- copy_user_highpage(dst, src, addr, vma);
- return true;
+ if (copy_mc_user_highpage(dst, src, addr, vma))
+ return -EHWPOISON;
+ return 0;
}
/*
@@ -2888,7 +2895,7 @@ static inline bool __wp_page_copy_user(struct page *dst, struct page *src,
* and update local tlb only
*/
update_mmu_tlb(vma, addr, vmf->pte);
- ret = false;
+ ret = -EAGAIN;
goto pte_unlock;
}
@@ -2913,7 +2920,7 @@ static inline bool __wp_page_copy_user(struct page *dst, struct page *src,
if (!likely(pte_same(*vmf->pte, vmf->orig_pte))) {
/* The PTE changed under us, update local tlb */
update_mmu_tlb(vma, addr, vmf->pte);
- ret = false;
+ ret = -EAGAIN;
goto pte_unlock;
}
@@ -2932,7 +2939,7 @@ static inline bool __wp_page_copy_user(struct page *dst, struct page *src,
}
}
- ret = true;
+ ret = 0;
pte_unlock:
if (locked)
@@ -3104,6 +3111,7 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
pte_t entry;
int page_copied = 0;
struct mmu_notifier_range range;
+ int ret;
delayacct_wpcopy_start();
@@ -3121,19 +3129,21 @@ static vm_fault_t wp_page_copy(struct vm_fault *vmf)
if (!new_page)
goto oom;
- if (!__wp_page_copy_user(new_page, old_page, vmf)) {
+ ret = __wp_page_copy_user(new_page, old_page, vmf);
+ if (ret) {
/*
* COW failed, if the fault was solved by other,
* it's fine. If not, userspace would re-fault on
* the same address and we will handle the fault
* from the second attempt.
+ * The -EHWPOISON case will not be retried.
*/
put_page(new_page);
if (old_page)
put_page(old_page);
delayacct_wpcopy_end();
- return 0;
+ return ret == -EHWPOISON ? VM_FAULT_HWPOISON : 0;
}
kmsan_copy_page_meta(new_page, old_page);
}
--
2.37.3Cannot call memory_failure() directly from the fault handler because
mmap_lock (and others) are held.
It is important, but not urgent, to mark the source page as h/w poisoned
and unmap it from other tasks.
Use memory_failure_queue() to request a call to memory_failure() for the
page with the error.
Also provide a stub version for CONFIG_MEMORY_FAILURE=n
Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Message-Id: <20221021200120.175753-3-tony.luck@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
---
include/linux/mm.h | 5 ++++-
mm/memory.c | 4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 8bbcccbc5565..03ced659eb58 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -3268,7 +3268,6 @@ enum mf_flags {
int mf_dax_kill_procs(struct address_space *mapping, pgoff_t index,
unsigned long count, int mf_flags);
extern int memory_failure(unsigned long pfn, int flags);
-extern void memory_failure_queue(unsigned long pfn, int flags);
extern void memory_failure_queue_kick(int cpu);
extern int unpoison_memory(unsigned long pfn);
extern int sysctl_memory_failure_early_kill;
@@ -3277,8 +3276,12 @@ extern void shake_page(struct page *p);
extern atomic_long_t num_poisoned_pages __read_mostly;
extern int soft_offline_page(unsigned long pfn, int flags);
#ifdef CONFIG_MEMORY_FAILURE
+extern void memory_failure_queue(unsigned long pfn, int flags);
extern int __get_huge_page_for_hwpoison(unsigned long pfn, int flags);
#else
+static inline void memory_failure_queue(unsigned long pfn, int flags)
+{
+}
static inline int __get_huge_page_for_hwpoison(unsigned long pfn, int flags)
{
return 0;
diff --git a/mm/memory.c b/mm/memory.c
index b6056eef2f72..eae242351726 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2866,8 +2866,10 @@ static inline int __wp_page_copy_user(struct page *dst, struct page *src,
unsigned long addr = vmf->address;
if (likely(src)) {
- if (copy_mc_user_highpage(dst, src, addr, vma))
+ if (copy_mc_user_highpage(dst, src, addr, vma)) {
+ memory_failure_queue(page_to_pfn(src), 0);
return -EHWPOISON;
+ }
return 0;
}
--
2.37.3Hi, Tony, Greg,
Does it make sense to include this patch series in the
5.15.y LTS kernel? I just checked: it's not in 5.15.112.
Thanks!
-jane
On 10/31/2022 1:10 PM, Tony Luck wrote:
> Cannot call memory_failure() directly from the fault handler because
> mmap_lock (and others) are held.
>
> It is important, but not urgent, to mark the source page as h/w poisoned
> and unmap it from other tasks.
>
> Use memory_failure_queue() to request a call to memory_failure() for the
> page with the error.
>
> Also provide a stub version for CONFIG_MEMORY_FAILURE=n
>
> Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
> Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>
> Signed-off-by: Tony Luck <tony.luck@intel.com>
> Message-Id: <20221021200120.175753-3-tony.luck@intel.com>
> Signed-off-by: Tony Luck <tony.luck@intel.com>
> ---
> include/linux/mm.h | 5 ++++-
> mm/memory.c | 4 +++-
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 8bbcccbc5565..03ced659eb58 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -3268,7 +3268,6 @@ enum mf_flags {
> int mf_dax_kill_procs(struct address_space *mapping, pgoff_t index,
> unsigned long count, int mf_flags);
> extern int memory_failure(unsigned long pfn, int flags);
> -extern void memory_failure_queue(unsigned long pfn, int flags);
> extern void memory_failure_queue_kick(int cpu);
> extern int unpoison_memory(unsigned long pfn);
> extern int sysctl_memory_failure_early_kill;
> @@ -3277,8 +3276,12 @@ extern void shake_page(struct page *p);
> extern atomic_long_t num_poisoned_pages __read_mostly;
> extern int soft_offline_page(unsigned long pfn, int flags);
> #ifdef CONFIG_MEMORY_FAILURE
> +extern void memory_failure_queue(unsigned long pfn, int flags);
> extern int __get_huge_page_for_hwpoison(unsigned long pfn, int flags);
> #else
> +static inline void memory_failure_queue(unsigned long pfn, int flags)
> +{
> +}
> static inline int __get_huge_page_for_hwpoison(unsigned long pfn, int flags)
> {
> return 0;
> diff --git a/mm/memory.c b/mm/memory.c
> index b6056eef2f72..eae242351726 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2866,8 +2866,10 @@ static inline int __wp_page_copy_user(struct page *dst, struct page *src,
> unsigned long addr = vmf->address;
>
> if (likely(src)) {
> - if (copy_mc_user_highpage(dst, src, addr, vma))
> + if (copy_mc_user_highpage(dst, src, addr, vma)) {
> + memory_failure_queue(page_to_pfn(src), 0);
> return -EHWPOISON;
> + }
> return 0;
> }
>
On Thu, May 18, 2023 at 02:49:44PM -0700, Jane Chu wrote:
> Hi, Tony, Greg,
>
> Does it make sense to include this patch series in the
> 5.15.y LTS kernel? I just checked: it's not in 5.15.112.
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
Jane,
You should do some analysis and testing to make sure that applying just this patch to 5.15.y works. There has been a bunch of recovery changes and I'm not sure if this depends on other changes.
-Tony
-----Original Message-----
From: Jane Chu <jane.chu@oracle.com>
Sent: Thursday, May 18, 2023 2:50 PM
To: Luck, Tony <tony.luck@intel.com>; Andrew Morton <akpm@linux-foundation.org>; Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Alexander Potapenko <glider@google.com>; Naoya Horiguchi <naoya.horiguchi@nec.com>; Miaohe Lin <linmiaohe@huawei.com>; Matthew Wilcox <willy@infradead.org>; Shuai Xue <xueshuai@linux.alibaba.com>; Williams, Dan J <dan.j.williams@intel.com>; linux-mm@kvack.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/2] mm, hwpoison: When copy-on-write hits poison, take page offline
Hi, Tony, Greg,
Does it make sense to include this patch series in the
5.15.y LTS kernel? I just checked: it's not in 5.15.112.
Thanks!
-jane
On 10/31/2022 1:10 PM, Tony Luck wrote:
> Cannot call memory_failure() directly from the fault handler because
> mmap_lock (and others) are held.
>
> It is important, but not urgent, to mark the source page as h/w poisoned
> and unmap it from other tasks.
>
> Use memory_failure_queue() to request a call to memory_failure() for the
> page with the error.
>
> Also provide a stub version for CONFIG_MEMORY_FAILURE=n
>
> Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
> Tested-by: Shuai Xue <xueshuai@linux.alibaba.com>
> Signed-off-by: Tony Luck <tony.luck@intel.com>
> Message-Id: <20221021200120.175753-3-tony.luck@intel.com>
> Signed-off-by: Tony Luck <tony.luck@intel.com>
> ---
> include/linux/mm.h | 5 ++++-
> mm/memory.c | 4 +++-
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 8bbcccbc5565..03ced659eb58 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -3268,7 +3268,6 @@ enum mf_flags {
> int mf_dax_kill_procs(struct address_space *mapping, pgoff_t index,
> unsigned long count, int mf_flags);
> extern int memory_failure(unsigned long pfn, int flags);
> -extern void memory_failure_queue(unsigned long pfn, int flags);
> extern void memory_failure_queue_kick(int cpu);
> extern int unpoison_memory(unsigned long pfn);
> extern int sysctl_memory_failure_early_kill;
> @@ -3277,8 +3276,12 @@ extern void shake_page(struct page *p);
> extern atomic_long_t num_poisoned_pages __read_mostly;
> extern int soft_offline_page(unsigned long pfn, int flags);
> #ifdef CONFIG_MEMORY_FAILURE
> +extern void memory_failure_queue(unsigned long pfn, int flags);
> extern int __get_huge_page_for_hwpoison(unsigned long pfn, int flags);
> #else
> +static inline void memory_failure_queue(unsigned long pfn, int flags)
> +{
> +}
> static inline int __get_huge_page_for_hwpoison(unsigned long pfn, int flags)
> {
> return 0;
> diff --git a/mm/memory.c b/mm/memory.c
> index b6056eef2f72..eae242351726 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2866,8 +2866,10 @@ static inline int __wp_page_copy_user(struct page *dst, struct page *src,
> unsigned long addr = vmf->address;
>
> if (likely(src)) {
> - if (copy_mc_user_highpage(dst, src, addr, vma))
> + if (copy_mc_user_highpage(dst, src, addr, vma)) {
> + memory_failure_queue(page_to_pfn(src), 0);
> return -EHWPOISON;
> + }
> return 0;
> }
>
在 2022/10/22 AM4:01, Tony Luck 写道: > Part 1 deals with the process that triggered the copy on write > fault with a store to a shared read-only page. That process is > send a SIGBUS with the usual machine check decoration to specify > the virtual address of the lost page, together with the scope. > > Part 2 sets up to asynchronously take the page with the uncorrected > error offline to prevent additional machine check faults. H/t to > Miaohe Lin <linmiaohe@huawei.com> and Shuai Xue <xueshuai@linux.alibaba.com> > for pointing me to the existing function to queue a call to > memory_failure(). > > On x86 there is some duplicate reporting (because the error is > also signalled by the memory controller as well as by the core > that triggered the machine check). Console logs look like this: > > [ 1647.723403] mce: [Hardware Error]: Machine check events logged > Machine check from kernel copy routine > > [ 1647.723414] MCE: Killing einj_mem_uc:3600 due to hardware memory corruption fault at 7f3309503400 > x86 fault handler sends SIGBUS to child process > > [ 1647.735183] Memory failure: 0x905b92d: recovery action for dirty LRU page: Recovered > Async call to memory_failure() from copy on write path The recovery action might also be handled asynchronously in CMCI uc_decode_notifier handler signaled by memory controller, right? I have a one more memory failure log than yours. [ 3187.485742] MCE: Killing einj_mem_uc:31746 due to hardware memory corruption fault at 7fc4bf7cf400 [ 3187.740620] Memory failure: 0x1a3b80: recovery action for dirty LRU page: Recovered uc_decode_notifier() processes memory controller report [ 3187.748272] Memory failure: 0x1a3b80: already hardware poisoned Workqueue: events memory_failure_work_func // queued by ghes_do_memory_failure [ 3187.754194] Memory failure: 0x1a3b80: already hardware poisoned Workqueue: events memory_failure_work_func // queued by __wp_page_copy_user [ 3188.615920] MCE: Killing einj_mem_uc:31745 due to hardware memory corruption fault at 7fc4bf7cf400 Best Regards, Shuai > > [ 1647.748397] Memory failure: 0x905b92d: already hardware poisoned > uc_decode_notifier() processes memory controller report > > [ 1647.761313] MCE: Killing einj_mem_uc:3599 due to hardware memory corruption fault at 7f3309503400 > Parent process tries to read poisoned page. Page has been unmapped, so > #PF handler sends SIGBUS > > > Tony Luck (2): > mm, hwpoison: Try to recover from copy-on write faults > mm, hwpoison: When copy-on-write hits poison, take page offline > > include/linux/highmem.h | 24 ++++++++++++++++++++++++ > include/linux/mm.h | 5 ++++- > mm/memory.c | 32 ++++++++++++++++++++++---------- > 3 files changed, 50 insertions(+), 11 deletions(-) >
在 2022/10/23 PM11:52, Shuai Xue 写道: > > > 在 2022/10/22 AM4:01, Tony Luck 写道: >> Part 1 deals with the process that triggered the copy on write >> fault with a store to a shared read-only page. That process is >> send a SIGBUS with the usual machine check decoration to specify >> the virtual address of the lost page, together with the scope. >> >> Part 2 sets up to asynchronously take the page with the uncorrected >> error offline to prevent additional machine check faults. H/t to >> Miaohe Lin <linmiaohe@huawei.com> and Shuai Xue <xueshuai@linux.alibaba.com> >> for pointing me to the existing function to queue a call to >> memory_failure(). >> >> On x86 there is some duplicate reporting (because the error is >> also signalled by the memory controller as well as by the core >> that triggered the machine check). Console logs look like this: >> >> [ 1647.723403] mce: [Hardware Error]: Machine check events logged >> Machine check from kernel copy routine >> >> [ 1647.723414] MCE: Killing einj_mem_uc:3600 due to hardware memory corruption fault at 7f3309503400 >> x86 fault handler sends SIGBUS to child process >> >> [ 1647.735183] Memory failure: 0x905b92d: recovery action for dirty LRU page: Recovered >> Async call to memory_failure() from copy on write path > > The recovery action might also be handled asynchronously in CMCI uc_decode_notifier > handler signaled by memory controller, right? > > I have a one more memory failure log than yours. > > [ 3187.485742] MCE: Killing einj_mem_uc:31746 due to hardware memory corruption fault at 7fc4bf7cf400 > [ 3187.740620] Memory failure: 0x1a3b80: recovery action for dirty LRU page: Recovered > uc_decode_notifier() processes memory controller report > > [ 3187.748272] Memory failure: 0x1a3b80: already hardware poisoned > Workqueue: events memory_failure_work_func // queued by ghes_do_memory_failure > > [ 3187.754194] Memory failure: 0x1a3b80: already hardware poisoned > Workqueue: events memory_failure_work_func // queued by __wp_page_copy_user > > [ 3188.615920] MCE: Killing einj_mem_uc:31745 due to hardware memory corruption fault at 7fc4bf7cf400 > > Best Regards, > Shuai Tested-by: Shuai Xue <xueshuai@linux.alibaba.com> Thank you. Shuai > >> >> [ 1647.748397] Memory failure: 0x905b92d: already hardware poisoned >> uc_decode_notifier() processes memory controller report >> >> [ 1647.761313] MCE: Killing einj_mem_uc:3599 due to hardware memory corruption fault at 7f3309503400 >> Parent process tries to read poisoned page. Page has been unmapped, so >> #PF handler sends SIGBUS >> >> >> Tony Luck (2): >> mm, hwpoison: Try to recover from copy-on write faults >> mm, hwpoison: When copy-on-write hits poison, take page offline >> >> include/linux/highmem.h | 24 ++++++++++++++++++++++++ >> include/linux/mm.h | 5 ++++- >> mm/memory.c | 32 ++++++++++++++++++++++---------- >> 3 files changed, 50 insertions(+), 11 deletions(-) >>
© 2016 - 2026 Red Hat, Inc.