Message ID | 20221031201029.102123-3-tony.luck@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp2524115wru; Mon, 31 Oct 2022 13:15:18 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4zDH8eSqmBhNCWx3ITogz8gmXvpiF4/r8NOpcuFMIhEno1hkmLf+K446RvJyISq4JlEaAr X-Received: by 2002:a17:906:8a48:b0:7a5:a8f5:b870 with SMTP id gx8-20020a1709068a4800b007a5a8f5b870mr14086426ejc.458.1667247318104; Mon, 31 Oct 2022 13:15:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1667247318; cv=none; d=google.com; s=arc-20160816; b=tMWEGsV/SspDgOPAgTV0zWeMrQ56kNIbU+ysqJRx5n6ruK27vltzB86m2mVDdD4BFv w+Ll0eOWFyAuJ1SsWy/tKHptl9FWrt424qtD9zJVWkhae9smYUSo73kj6ppUKDChQ1GI 6KInWDCzKt497104aQuzofN1AALUsXDbgY1KmdjzzEM51MUaZxiLUZ5r1VxDC4BW8cBX 0L9ETGZHcUPbh8th1dsljAw7e+gxbIIKEAiJK4yJTBFcVSkZnvrr/zWUr7H0YV9MTigc qBWaiyf5aN7TL5QAqwgScm5zPDxWXsY8Ya9u7X7pfDgo6Bssc8wM5yiIKbRwIshWZVVW dnRw== 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 :dkim-signature; bh=HybuBLpFrKjUpj8nbH2WjkWYl9KfidiuqjYNV1CeozA=; b=kywhUwFL11D+Oodb8FMMx5lbtl1uQw1rBAolAoNV0ouSrUnz+DOcg5xfbxO+eOFKVa H0+LlTMSHxH82s/7iElQemitz/TdIzd63XYmdc9y/hL/sOVBsBeNqYaxM43x2wAfowKZ YBryRuQpH3zo+53Tn5/5pPx4lL+b6RujLyHZKbzkxa5zyWyGtFMD3sINAw2rX3CqmmOa JrhcG+4mWh//XwInZ07Njr/enPrkjSKyWZFJoIVKxpnxJcL47KAyt9Q03q8RoR/ens/Q qot5S7teZkFqO/flw5+ladcdjZO1DMwQkMq3coxhGLYCvceXHP+XpBQDnr+RpirjY9nC Cpqw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=oJhbbdJx; 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=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hz5-20020a1709072ce500b007ad8218a472si9537039ejc.242.2022.10.31.13.14.50; Mon, 31 Oct 2022 13:15:18 -0700 (PDT) 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; dkim=pass header.i=@intel.com header.s=Intel header.b=oJhbbdJx; 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=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229849AbiJaUK4 (ORCPT <rfc822;kartikey406@gmail.com> + 99 others); Mon, 31 Oct 2022 16:10:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44684 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229667AbiJaUKt (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 31 Oct 2022 16:10:49 -0400 Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 14D1BC6C for <linux-kernel@vger.kernel.org>; Mon, 31 Oct 2022 13:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1667247049; x=1698783049; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=/v2ZvqyUX9QuQjryssW2yaZzhbAsEUWDkNYvgzcoQls=; b=oJhbbdJx2yqz2UFya/z7eh9aPA2m/Tqsms5Z7x155lLOqy+Tkr2NFb7k r+J4oJKec1TJgxQBNy0Udd619gV/KZuO+Prxfz7Ff7XKpvpfCshOu37Gw lbe2Oo8FoAz2sHhdTJgXVt/YpTmen7KtZqkxgJif9Dz+1WBkAgyKMjBsu XWKMDKwjkofXb1Y7Qn9G+uF5XqwWlrbVTC25l2lnvC/ivEhyHDeHJVen3 tCRDFWzOy2SbkWbpYNqqHM1jPpN4mjFuB+ySPvyR66F0z/yJfBRYA1ZQQ hi7VceuhRRTx03HywBB5b8ZVHK+Bf3XbdMadgTQgJiQt1kt0p21Yvogxe w==; X-IronPort-AV: E=McAfee;i="6500,9779,10517"; a="335651895" X-IronPort-AV: E=Sophos;i="5.95,228,1661842800"; d="scan'208";a="335651895" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Oct 2022 13:10:47 -0700 X-IronPort-AV: E=McAfee;i="6500,9779,10517"; a="722931446" X-IronPort-AV: E=Sophos;i="5.95,228,1661842800"; d="scan'208";a="722931446" Received: from agluck-desk3.sc.intel.com ([172.25.222.78]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Oct 2022 13:10:47 -0700 From: Tony Luck <tony.luck@intel.com> To: Andrew Morton <akpm@linux-foundation.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>, Dan Williams <dan.j.williams@intel.com>, Michael Ellerman <mpe@ellerman.id.au>, Nicholas Piggin <npiggin@gmail.com>, Christophe Leroy <christophe.leroy@csgroup.eu>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Tony Luck <tony.luck@intel.com> Subject: [PATCH v4 2/2] mm, hwpoison: When copy-on-write hits poison, take page offline Date: Mon, 31 Oct 2022 13:10:29 -0700 Message-Id: <20221031201029.102123-3-tony.luck@intel.com> X-Mailer: git-send-email 2.37.3 In-Reply-To: <20221031201029.102123-1-tony.luck@intel.com> References: <20221021200120.175753-1-tony.luck@intel.com> <20221031201029.102123-1-tony.luck@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE 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?1747329095532355117?= X-GMAIL-MSGID: =?utf-8?q?1748235523983395704?= |
Series |
Copy-on-write poison recovery
|
|
Commit Message
Luck, Tony
Oct. 31, 2022, 8:10 p.m. UTC
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(-)
Comments
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; > } >
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; > } >
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>
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; }