Message ID | 20221209072801.193221-1-wangkefeng.wang@huawei.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp627791wrr; Thu, 8 Dec 2022 23:27:10 -0800 (PST) X-Google-Smtp-Source: AA0mqf4CdrCvi8Gxqvz7tV4+trM22LGPWQcnjMMIAeRU45m9EDIuryjfpFNN0RK8qLxuDjvtP2fw X-Received: by 2002:a17:907:c20c:b0:7c1:337e:5755 with SMTP id ti12-20020a170907c20c00b007c1337e5755mr3329550ejc.26.1670570830593; Thu, 08 Dec 2022 23:27:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670570830; cv=none; d=google.com; s=arc-20160816; b=eOqP8dsu0xUJ7j/xSxeD1yeliqm13WZXEqbJb7Z/dzdV4bcOnsMbtHHy77jqTTYB6q EzVbzRpPFYf2jOIFi+1qUdUeqDLwTCh0hRq+VVJ7AqoZZNcFVaoD4I6QlggjjhPsPRtr OF9ympVR5r1GU5E+HRDwnUeFIwqMk12wIsKVZuOXjcXvdtuLAht/cEUrIJaMuimKMfV0 OBiR6E9nNj90JUEcn1eHHseH6VHDQQWbfHSBcXSp7Wt9vFWrwaMSEeCqnp9yipAf0l3q GNTQ6ZG69kwJGHX0WtPuCruZ/alChtel5KVRD+JWWoSmXkPje+0jCTgW6u9A06DYIKHs fJOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=XgPLd+iHHlrs52USbNQltXdZaLcuZOcleqibYghZXIw=; b=dY0TGAz0co6nxW9lVDGACUtFoCo28yi1wUdZxSC7GtAu3kCSKswvNXJAlJv4GBOHuN 9mnk5BIGvwMIc0yLQ8XVrUSUFnrYE1fJ4w4THqx5S0pjPvOd6mzrjrOmdnjXM/kFhWU9 1CHhSRFrsTIc7kgUKyLaVIlM8FCKLB/sXu3t+VEdzui5rO61KkDf3gj5tBLlDdbHmqO7 CQl2Hfm56UxB2p3vJaP/qI5Y96C5nYwGFz9NqDaHRIP42yVhub++hKuv98C0UzHsb30I QlQwbmyXLr9Vkb+41cRwq5bTZpKcdmrpR42JcTb9aU9Hg2tcFTPxCdsWBL0Jzpx6GW9D AUbA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id xa3-20020a170906fd8300b007c11812c621si613353ejb.459.2022.12.08.23.26.46; Thu, 08 Dec 2022 23:27:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229661AbiLIHMT (ORCPT <rfc822;sophiezhao968@gmail.com> + 99 others); Fri, 9 Dec 2022 02:12:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229728AbiLIHMR (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 9 Dec 2022 02:12:17 -0500 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E05D73057C for <linux-kernel@vger.kernel.org>; Thu, 8 Dec 2022 23:12:16 -0800 (PST) Received: from dggpemm500001.china.huawei.com (unknown [172.30.72.55]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4NT2Dm2Lm1zJpCN; Fri, 9 Dec 2022 15:08:40 +0800 (CST) Received: from localhost.localdomain.localdomain (10.175.113.25) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 9 Dec 2022 15:11:38 +0800 From: Kefeng Wang <wangkefeng.wang@huawei.com> To: <naoya.horiguchi@nec.com>, <akpm@linux-foundation.org>, <linux-mm@kvack.org> CC: <tony.luck@intel.com>, <linux-kernel@vger.kernel.org>, <linmiaohe@huawei.com>, Kefeng Wang <wangkefeng.wang@huawei.com> Subject: [PATCH -next v2] mm: hwposion: support recovery from ksm_might_need_to_copy() Date: Fri, 9 Dec 2022 15:28:01 +0800 Message-ID: <20221209072801.193221-1-wangkefeng.wang@huawei.com> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20221209021525.196276-1-wangkefeng.wang@huawei.com> References: <20221209021525.196276-1-wangkefeng.wang@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.113.25] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm500001.china.huawei.com (7.185.36.107) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1751699711580564857?= X-GMAIL-MSGID: =?utf-8?q?1751720479130561235?= |
Series |
[-next,v2] mm: hwposion: support recovery from ksm_might_need_to_copy()
|
|
Commit Message
Kefeng Wang
Dec. 9, 2022, 7:28 a.m. UTC
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(-)
Comments
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);