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 56EAAC5320E for ; Tue, 20 Aug 2024 09:13:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A2BEC6B007B; Tue, 20 Aug 2024 05:13:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DBE56B0082; Tue, 20 Aug 2024 05:13:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A5226B0083; Tue, 20 Aug 2024 05:13:03 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6BBBA6B007B for ; Tue, 20 Aug 2024 05:13:03 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 0AA841415E8 for ; Tue, 20 Aug 2024 09:13:03 +0000 (UTC) X-FDA: 82472059446.10.4731D4A Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf03.hostedemail.com (Postfix) with ESMTP id 0CFB420005 for ; Tue, 20 Aug 2024 09:13:00 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf03.hostedemail.com: domain of mark.rutland@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=mark.rutland@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724145104; 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=yZa8XNLTFH/TYxB/6ufFQyi9yG0Lr3zYGfPaAE99nzw=; b=B+SvKuHBfS9a6I4M3Q7qxt7gpAoF/aT0KomhQ/YLudNBOLpEhBSCvZwQdIt6waEx51Pz6Y EG5iNZ7ySmqAjo4CcBr72jfqooe9f2iL//3funiT69Y+oUkMYy1iDfaOXmLi73wr7rS9/U G8IVwQsY0KOjTltw+q9RmVtEyyPQ9Yg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724145104; a=rsa-sha256; cv=none; b=v26MwbwEL+X1gKlU4ecFrBt5k6ADDa5v2XgzK6sYVqPTxZATD4us1f7Hl5dYgs7PtVUFzs iA2xqtibkl0fQBScwnpD5jucJhOE/42vK6ND2HHi1FOeVukncPIeT9rMDixAxkAdmLO+I8 Zt+Nje9wDKHmC0Zn0WYYybNFh1W0d/s= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf03.hostedemail.com: domain of mark.rutland@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=mark.rutland@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DB16ADA7; Tue, 20 Aug 2024 02:13:25 -0700 (PDT) Received: from J2N7QTR9R3 (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3BA6B3F66E; Tue, 20 Aug 2024 02:12:55 -0700 (PDT) Date: Tue, 20 Aug 2024 10:12:47 +0100 From: Mark Rutland To: Tong Tiangen Cc: Catalin Marinas , Will Deacon , Andrew Morton , James Morse , Robin Murphy , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Michael Ellerman , Nicholas Piggin , Andrey Ryabinin , Alexander Potapenko , Christophe Leroy , "Aneesh Kumar K.V" , "Naveen N. Rao" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, wangkefeng.wang@huawei.com, Guohanjun Subject: Re: [PATCH v12 2/6] arm64: add support for ARCH_HAS_COPY_MC Message-ID: References: <20240528085915.1955987-1-tongtiangen@huawei.com> <20240528085915.1955987-3-tongtiangen@huawei.com> <4436d172-c474-8ecd-b5e4-4c21088baf49@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4436d172-c474-8ecd-b5e4-4c21088baf49@huawei.com> X-Rspamd-Queue-Id: 0CFB420005 X-Stat-Signature: witjbuiuz47e9i1sh8f5gjuud93gr6w1 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1724145180-806303 X-HE-Meta: U2FsdGVkX19mY5LHleSAYklReVLWiDeGaHzP44+Fwxpd7TmrxpCDQ5ddhzMzhZx8sTL172j9x5LbRbDvvaTxhKgmgfjaXYp82wIC67TAy6nxmrT086oMd+VSsb0fzN9WBKTWzYpE5qeHl0NuEHN8mrWJG1CCsxaWLXi36BhO+wRNdxEZ9sDMfMBTWuoSARgOocFYY09SlvQAGwM6zuz8t7iq13UgqbblXgwJQdoPcbLbaIPIgavScCmNljY9BkdpnHVAWsk1ob3wRPqg8sneMN+VwBG61bZzLpg14Zzuqp0pjTSATuetwA+LpJeD1taIRBQl5CoAt1GEx/OrgxYzRarFFndsIisUMuIIxZfSQhVIeF04WMhP3gQt5ZZCDARh61v4ljLAeydFdI9H4QT5xxsZ0BxI3KYOYc9gi1/ZF8aJEF3zeMKii1nrdOr98DGiqJdW8ax3I/6xWw7agQ6SJMeDWqdK1ZuSeR0tHxyLlVWE5ErBGcO14LsP2W8XWUz1Uk52KsDu0dsUEHrpFbG/z+R/7QDeVqhUaRbkzRZ5DHzyaCE1q0ZTZAQv102YxoH3iqSb5dub3W2qPiiDSgOs+mYjoLu2Ep17/oRc/mo2pV0I5il7385qonTtTgntVzlbR7fAgCvXuI6mnpV5DYBz5sqWz0UERRBcoK0icCIq8UfBur5W4c15bSdbtfTKG+Pr4yxMA9q45oyK5muCjkrZJGTny6VYhf/qlEcqu8gv8HUPDsrSYQmRZiEt33IrjCyj1Nym8HVebS1mSm/X8tRBYgLmA0Al61XhKV7o7YXTNw1WqX7TedR3Il6pblG3mvEQlNGPnzgt85gcl+qBFgiYHne8O2ZKeCY8D9yS183adp0+cU56Sm8SHgvP03LjaP+IZd4fn3MSeiLiAuxRqaivujrjazHFFGzW1SnVwFz0cgVRqtkXrwr4crF9j+/aWw0DcDFICFQIYAIynd3zpYn ylYhLk68 yhr9qheX49pt4o/3nmzxWDQJNzpKDKy2cFbj+NvyuU3/Ay83ySwBBmUwtHKdYCyjrLucdT9kKILBSuT5kII58paOu/YkG10OnxCdhMAiaQfuNikJ1+8f4rS+HYL9cN3mx7yKYoB2wkG5jgcu11C2ppZ/BL5bsmJgqBYbrEgCb3DcVXk0zKeboPhKkykA24b+ukSkFISRfJvWWm63vfZnrtOpcPAyndbxnI89bzs4XIcfcY6uwWC9/f17e8saSIGRiLQ/jjT1qcNUjlPGTrPITRBfCtPgZ4yLBiZiIkafwW45WbTVMJjCn1xAmyw== 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: List-Subscribe: List-Unsubscribe: On Tue, Aug 20, 2024 at 10:11:45AM +0800, Tong Tiangen wrote: > 在 2024/8/20 1:29, Mark Rutland 写道: > > Hi Tong, > > > > On Tue, May 28, 2024 at 04:59:11PM +0800, Tong Tiangen wrote: > > > For the arm64 kernel, when it processes hardware memory errors for > > > synchronize notifications(do_sea()), if the errors is consumed within the > > > kernel, the current processing is panic. However, it is not optimal. > > > > > > Take copy_from/to_user for example, If ld* triggers a memory error, even in > > > kernel mode, only the associated process is affected. Killing the user > > > process and isolating the corrupt page is a better choice. > > > > > > New fixup type EX_TYPE_KACCESS_ERR_ZERO_ME_SAFE is added to identify insn > > > that can recover from memory errors triggered by access to kernel memory. > > > > > > Signed-off-by: Tong Tiangen [...] > > > diff --git a/arch/arm64/include/asm/asm-extable.h b/arch/arm64/include/asm/asm-extable.h > > > index 980d1dd8e1a3..9c0664fe1eb1 100644 > > > --- a/arch/arm64/include/asm/asm-extable.h > > > +++ b/arch/arm64/include/asm/asm-extable.h > > > @@ -5,11 +5,13 @@ > > > #include > > > #include > > > -#define EX_TYPE_NONE 0 > > > -#define EX_TYPE_BPF 1 > > > -#define EX_TYPE_UACCESS_ERR_ZERO 2 > > > -#define EX_TYPE_KACCESS_ERR_ZERO 3 > > > -#define EX_TYPE_LOAD_UNALIGNED_ZEROPAD 4 > > > +#define EX_TYPE_NONE 0 > > > +#define EX_TYPE_BPF 1 > > > +#define EX_TYPE_UACCESS_ERR_ZERO 2 > > > +#define EX_TYPE_KACCESS_ERR_ZERO 3 > > > +#define EX_TYPE_LOAD_UNALIGNED_ZEROPAD 4 > > > +/* kernel access memory error safe */ > > > +#define EX_TYPE_KACCESS_ERR_ZERO_ME_SAFE 5 > > > > Could we please use 'MEM_ERR', and likewise for the macros below? That's > > more obvious than 'ME_SAFE', and we wouldn't need the comment here. > > Likewise elsewhere in this patch and the series. > > > > To Jonathan's comment, I do prefer these numbers are aligned, so aside > > from the naming, the diff above looks good. > > OK, I also modified other locations to use 'MEM_ERR'. Thanks! [...] > > > diff --git a/arch/arm64/lib/copy_to_user.S b/arch/arm64/lib/copy_to_user.S > > > index 802231772608..2ac716c0d6d8 100644 > > > --- a/arch/arm64/lib/copy_to_user.S > > > +++ b/arch/arm64/lib/copy_to_user.S > > > @@ -20,7 +20,7 @@ > > > * x0 - bytes not copied > > > */ > > > .macro ldrb1 reg, ptr, val > > > - ldrb \reg, [\ptr], \val > > > + KERNEL_ME_SAFE(9998f, ldrb \reg, [\ptr], \val) > > > .endm > > > .macro strb1 reg, ptr, val > > > @@ -28,7 +28,7 @@ > > > .endm > > > .macro ldrh1 reg, ptr, val > > > - ldrh \reg, [\ptr], \val > > > + KERNEL_ME_SAFE(9998f, ldrh \reg, [\ptr], \val) > > > .endm > > > .macro strh1 reg, ptr, val > > > @@ -36,7 +36,7 @@ > > > .endm > > > .macro ldr1 reg, ptr, val > > > - ldr \reg, [\ptr], \val > > > + KERNEL_ME_SAFE(9998f, ldr \reg, [\ptr], \val) > > > .endm > > > .macro str1 reg, ptr, val > > > @@ -44,7 +44,7 @@ > > > .endm > > > .macro ldp1 reg1, reg2, ptr, val > > > - ldp \reg1, \reg2, [\ptr], \val > > > + KERNEL_ME_SAFE(9998f, ldp \reg1, \reg2, [\ptr], \val) > > > .endm > > > .macro stp1 reg1, reg2, ptr, val > > > > These changes mean that regular copy_to_user() will handle kernel memory > > errors, rather than only doing that in copy_mc_to_user(). If that's > > intentional, please call that out explicitly in the commit message. > > Yes. This is the purpose of the modification. If the copy_to_user() > function encounters a memory error, this uaccess affects only the > current process. and only need to kill the current process instead of > the entire kernel panic. Do not add copy_mc_to_user() so that > copy_to_user() can process memory errors. > > I'll add a description in the commit msg next version. Ok; why do powerpc and x86 have separate copy_mc_to_user() implementations, then? [...] > > > +/* > > > + * APEI claimed this as a firmware-first notification. > > > + * Some processing deferred to task_work before ret_to_user(). > > > + */ > > > +static bool do_apei_claim_sea(struct pt_regs *regs) > > > +{ > > > + if (user_mode(regs)) { > > > + if (!apei_claim_sea(regs)) > > > + return true; > > > + } else if (IS_ENABLED(CONFIG_ARCH_HAS_COPY_MC)) { > > > + if (fixup_exception_me(regs) && !apei_claim_sea(regs)) > > > + return true; > > > + } > > > + > > > + return false; > > > +} > > > > Hmm... that'll fixup the exception even if we don't manage to claim a > > the SEA. I suspect this should probably be: > > > > static bool do_apei_claim_sea(struct pt_regs *regs) > > { > > if (apei_claim_sea(regs)) > > return false; > > if (user_mode(regs)) > > return true; > > if (IS_ENABLED(CONFIG_ARCH_HAS_COPY_MC)) > > return !fixup_excepton_mem_err(regs); > > > > return false; > > } > > > > ... unless we *don't* want to claim the SEA in the case we don't have a > > fixup? > > > > Mark. > > > > Yes. My original meaning here is that if not have fixup, panic is > performed in do_sea() according to the original logic, and claim sea is > not required. AFAICT my suggestion doesn't change that; if we don't have a fixup the proprosed do_apei_claim_sea() would return false, and so do_sea() would caryy on to arm64_notify_die(...). I'm specifically asking if we need to avoid calling apei_claim_sea() when we don't have a fixup handler, or if calling that would be fine. One important thing is that if apei_claim_sea() fails to claim the SEA, we'd like to panic(), and in that case it'd be good to have not applied the fixup handler, so that the pt_regs::pc shows where the fault was taken from. Mark.