| Message ID | 20221209072801.193221-1-wangkefeng.wang@huawei.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [-next,v2] mm: hwposion: support recovery from ksm_might_need_to_copy() | expand |
On Fri, 9 Dec 2022 15:28:01 +0800 Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > When the kernel copy a page from ksm_might_need_to_copy(), but runs > into an uncorrectable error, it will crash since poisoned page is > consumed by kernel, this is similar to Copy-on-write poison recovery, > When an error is detected during the page copy, return VM_FAULT_HWPOISON, > which help us to avoid system crash. Note, memory failure on a KSM > page will be skipped, but still call memory_failure_queue() to be > consistent with general memory failure process. Thanks. Sorry, lots of paperwork and bureaucracy: Is a copy of the oops(?) output available? Did someone else report this? If so, is a Reported-by available for that? And a Link: for the Reported-by:, which is a coming thing. Can we identify a Fixes: target? Is a cc:stable appropriate?
On 2022/12/10 8:50, Andrew Morton wrote: > On Fri, 9 Dec 2022 15:28:01 +0800 Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > >> When the kernel copy a page from ksm_might_need_to_copy(), but runs >> into an uncorrectable error, it will crash since poisoned page is >> consumed by kernel, this is similar to Copy-on-write poison recovery, >> When an error is detected during the page copy, return VM_FAULT_HWPOISON, >> which help us to avoid system crash. Note, memory failure on a KSM >> page will be skipped, but still call memory_failure_queue() to be >> consistent with general memory failure process. > Thanks. Sorry, lots of paperwork and bureaucracy: > > > Is a copy of the oops(?) output available? > > Did someone else report this? If so, is a Reported-by available for > that? And a Link: for the Reported-by:, which is a coming thing. > > Can we identify a Fixes: target? > > Is a cc:stable appropriate? We are trying to support ARCH_HAS_COPY_MC on arm64[1] and trying to recover from CoW faults[2], also tony do the same thing(recover from CoW) on X86[3]. The kernel copy in ksm_might_need_to_copy() could recover, this is an enhance of COPY_MC, so I think no need to add Fixes and stable. Thanks. [1] https://lore.kernel.org/linux-arm-kernel/20220812070557.1028499-1-tongtiangen@huawei.com/ [2] https://lore.kernel.org/linux-arm-kernel/20220812070557.1028499-5-tongtiangen@huawei.com/ [3] https://lore.kernel.org/lkml/20221031201029.102123-2-tony.luck@intel.com/ >
On 2022/12/9 15:28, Kefeng Wang wrote: > When the kernel copy a page from ksm_might_need_to_copy(), but runs > into an uncorrectable error, it will crash since poisoned page is > consumed by kernel, this is similar to Copy-on-write poison recovery, > When an error is detected during the page copy, return VM_FAULT_HWPOISON, > which help us to avoid system crash. Note, memory failure on a KSM > page will be skipped, but still call memory_failure_queue() to be > consistent with general memory failure process. Thanks for your patch. > > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> > --- > v2: fix type error > > mm/ksm.c | 8 ++++++-- > mm/memory.c | 3 +++ > mm/swapfile.c | 2 +- > 3 files changed, 10 insertions(+), 3 deletions(-) > > diff --git a/mm/ksm.c b/mm/ksm.c > index dd02780c387f..83e2f74ae7da 100644 > --- a/mm/ksm.c > +++ b/mm/ksm.c > @@ -2629,8 +2629,12 @@ struct page *ksm_might_need_to_copy(struct page *page, > new_page = NULL; > } > if (new_page) { > - copy_user_highpage(new_page, page, address, vma); > - > + if (copy_mc_user_highpage(new_page, page, address, vma)) { > + put_page(new_page); > + new_page = ERR_PTR(-EHWPOISON); > + memory_failure_queue(page_to_pfn(page), 0); > + return new_page; > + } > SetPageDirty(new_page); > __SetPageUptodate(new_page); > __SetPageLocked(new_page); > diff --git a/mm/memory.c b/mm/memory.c > index aad226daf41b..5b2c137dfb2a 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -3840,6 +3840,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > if (unlikely(!page)) { > ret = VM_FAULT_OOM; > goto out_page; > + } else if (unlikely(PTR_ERR(page) == -EHWPOISON)) { > + ret = VM_FAULT_HWPOISON; > + goto out_page; > } > folio = page_folio(page); > > diff --git a/mm/swapfile.c b/mm/swapfile.c > index 908a529bca12..d479811bc311 100644 > --- a/mm/swapfile.c > +++ b/mm/swapfile.c > @@ -1767,7 +1767,7 @@ static int unuse_pte(struct vm_area_struct *vma, pmd_t *pmd, > > swapcache = page; > page = ksm_might_need_to_copy(page, vma, addr); > - if (unlikely(!page)) > + if (IS_ERR_OR_NULL(page)) IMHO, it might be better to install a hwpoison entry here. Or later swapoff ops will trigger the uncorrectable error again? Thanks, Miaohe Lin
On 2022/12/12 10:36, Miaohe Lin wrote: > On 2022/12/9 15:28, Kefeng Wang wrote: >> When the kernel copy a page from ksm_might_need_to_copy(), but runs >> into an uncorrectable error, it will crash since poisoned page is >> consumed by kernel, this is similar to Copy-on-write poison recovery, >> When an error is detected during the page copy, return VM_FAULT_HWPOISON, >> which help us to avoid system crash. Note, memory failure on a KSM >> page will be skipped, but still call memory_failure_queue() to be >> consistent with general memory failure process. ... > > diff --git a/mm/swapfile.c b/mm/swapfile.c > index 908a529bca12..d479811bc311 100644 > --- a/mm/swapfile.c > +++ b/mm/swapfile.c > @@ -1767,7 +1767,7 @@ static int unuse_pte(struct vm_area_struct *vma, pmd_t *pmd, > > swapcache = page; > page = ksm_might_need_to_copy(page, vma, addr); > - if (unlikely(!page)) > + if (IS_ERR_OR_NULL(page)) > IMHO, it might be better to install a hwpoison entry here. Or later swapoff ops will trigger > the uncorrectable error again? Thanks for you suggestion, will do in v3. > Thanks, > Miaohe Lin >
diff --git a/mm/ksm.c b/mm/ksm.c index dd02780c387f..83e2f74ae7da 100644 --- a/mm/ksm.c +++ b/mm/ksm.c @@ -2629,8 +2629,12 @@ struct page *ksm_might_need_to_copy(struct page *page, new_page = NULL; } if (new_page) { - copy_user_highpage(new_page, page, address, vma); - + if (copy_mc_user_highpage(new_page, page, address, vma)) { + put_page(new_page); + new_page = ERR_PTR(-EHWPOISON); + memory_failure_queue(page_to_pfn(page), 0); + return new_page; + } SetPageDirty(new_page); __SetPageUptodate(new_page); __SetPageLocked(new_page); diff --git a/mm/memory.c b/mm/memory.c index aad226daf41b..5b2c137dfb2a 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -3840,6 +3840,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) if (unlikely(!page)) { ret = VM_FAULT_OOM; goto out_page; + } else if (unlikely(PTR_ERR(page) == -EHWPOISON)) { + ret = VM_FAULT_HWPOISON; + goto out_page; } folio = page_folio(page); diff --git a/mm/swapfile.c b/mm/swapfile.c index 908a529bca12..d479811bc311 100644 --- a/mm/swapfile.c +++ b/mm/swapfile.c @@ -1767,7 +1767,7 @@ static int unuse_pte(struct vm_area_struct *vma, pmd_t *pmd, swapcache = page; page = ksm_might_need_to_copy(page, vma, addr); - if (unlikely(!page)) + if (IS_ERR_OR_NULL(page)) return -ENOMEM; pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
When the kernel copy a page from ksm_might_need_to_copy(), but runs into an uncorrectable error, it will crash since poisoned page is consumed by kernel, this is similar to Copy-on-write poison recovery, When an error is detected during the page copy, return VM_FAULT_HWPOISON, which help us to avoid system crash. Note, memory failure on a KSM page will be skipped, but still call memory_failure_queue() to be consistent with general memory failure process. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> --- v2: fix type error mm/ksm.c | 8 ++++++-- mm/memory.c | 3 +++ mm/swapfile.c | 2 +- 3 files changed, 10 insertions(+), 3 deletions(-)