From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 070F2ECAAA1 for ; Fri, 28 Oct 2022 02:12:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3044B6B0072; Thu, 27 Oct 2022 22:12:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 28DE26B0073; Thu, 27 Oct 2022 22:12:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12FA18E0001; Thu, 27 Oct 2022 22:12:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 03D9C6B0072 for ; Thu, 27 Oct 2022 22:12:07 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id C4927AB163 for ; Fri, 28 Oct 2022 02:12:06 +0000 (UTC) X-FDA: 80068733052.18.F23F5A5 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf21.hostedemail.com (Postfix) with ESMTP id 4141B1C0009 for ; Fri, 28 Oct 2022 02:12:02 +0000 (UTC) Received: from canpemm500002.china.huawei.com (unknown [172.30.72.53]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4Mz5X1670Xz15MFB; Fri, 28 Oct 2022 10:06:57 +0800 (CST) Received: from [10.174.151.185] (10.174.151.185) by canpemm500002.china.huawei.com (7.192.104.244) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Fri, 28 Oct 2022 10:11:52 +0800 Subject: Re: [PATCH v3 1/2] mm, hwpoison: Try to recover from copy-on write faults To: Tony Luck CC: Matthew Wilcox , Shuai Xue , Dan Williams , Michael Ellerman , Nicholas Piggin , Christophe Leroy , , , , Naoya Horiguchi , Andrew Morton References: <20221019170835.155381-1-tony.luck@intel.com> <20221021200120.175753-1-tony.luck@intel.com> <20221021200120.175753-2-tony.luck@intel.com> From: Miaohe Lin Message-ID: Date: Fri, 28 Oct 2022 10:11:51 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20221021200120.175753-2-tony.luck@intel.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.151.185] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To canpemm500002.china.huawei.com (7.192.104.244) X-CFilter-Loop: Reflected ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; spf=pass (imf21.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666923126; a=rsa-sha256; cv=none; b=ZocJy7Jtxozz3EZKHSBy91LLAGQmicJHXLOEFBvNm4WhxvHxNT07TMWXhwn4O5xHDPnaCx bJZvY9EYtkJJocytQJeji12qS9tpdY2+/geO7dl48W+VzIY8igYOlKKwo9s6T9umL8ZEaC GOYjrTjZIlXGEvLJq9X/4BSkxC/nXHw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666923126; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MQnJOwjtKXbapqhHwsAELFHsQ6IqkzLVz2KYpvlEUO0=; b=D7THDz86gWSs4vZqFtNt6SqlaeQ4M/A5tAxHhtD2OiumdCBk+IPdlE2CekCpe4muNXLxcD CpxsduJOHWNtZBgsv8d4I2imBA9j0dZXhycxJPi9pndwEqFPqvOrccjFcKDSsVAPNPJWL+ VOKpVB47zZr6TiUBJjNPCVmw5ctTOlg= X-Rspam-User: X-Rspamd-Queue-Id: 4141B1C0009 Authentication-Results: imf21.hostedemail.com; dkim=none; spf=pass (imf21.hostedemail.com: domain of linmiaohe@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=linmiaohe@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-Stat-Signature: msxhg8hzp6ioqzju3pai1a6odw5p7smq X-Rspamd-Server: rspam10 X-HE-Tag: 1666923122-443963 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 2022/10/22 4:01, Tony Luck wrote: > 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 > Signed-off-by: Tony Luck Thanks for your work, Tony. > > --- > Changes in V3: > Dan Williams > Rename copy_user_highpage_mc() to copy_mc_user_highpage() for > consistency with Linus' discussion on names of functions that > check for machine check. > Write complete functions for the have/have-not copy_mc_to_kernel > cases (so grep shows there are two versions) > Change __wp_page_copy_user() to return 0 for success, negative for fail > [I picked -EAGAIN for both non-EHWPOISON cases] > > Changes in V2: > Naoya Horiguchi: > 1) Use -EHWPOISON error code instead of minus one. > 2) Poison path needs also to deal with old_page > Tony Luck: > Rewrote commit message > Added some powerpc folks to Cc: list > --- > include/linux/highmem.h | 24 ++++++++++++++++++++++++ > mm/memory.c | 30 ++++++++++++++++++++---------- > 2 files changed, 44 insertions(+), 10 deletions(-) > > diff --git a/include/linux/highmem.h b/include/linux/highmem.h > index e9912da5441b..a32c64681f03 100644 > --- a/include/linux/highmem.h > +++ b/include/linux/highmem.h > @@ -319,6 +319,30 @@ 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); In copy_user_highpage(), kmsan_unpoison_memory(page_address(to), PAGE_SIZE) is done after the copy when __HAVE_ARCH_COPY_USER_HIGHPAGE isn't defined. Do we need to do something similar here? But I'm not familiar with kmsan, so I can easy be wrong. Anyway, this patch looks good to me. Thanks. Reviewed-by: Miaohe Lin Thanks, Miaohe Lin