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 1B7CEC021A4 for ; Wed, 12 Feb 2025 16:21:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A5AE86B0089; Wed, 12 Feb 2025 11:21:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E358280001; Wed, 12 Feb 2025 11:21:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 883DC6B008C; Wed, 12 Feb 2025 11:21:29 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 6711B6B0089 for ; Wed, 12 Feb 2025 11:21:29 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 2710C1C9652 for ; Wed, 12 Feb 2025 16:21:29 +0000 (UTC) X-FDA: 83111807898.18.F99F87B Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf04.hostedemail.com (Postfix) with ESMTP id 23FB440006 for ; Wed, 12 Feb 2025 16:21:26 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of cmarinas@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739377287; a=rsa-sha256; cv=none; b=VbFS9WTgCQDc+OxoOpRmEc+Hdohn8pRIw5VZzrZugR01bBqPRilOT/bzmEhD46Sp9IQYkK mbE7r9qaljqqrskzSxSQUjTJ7zPL/HsLu44m531Udp0oYhDGGUSCh57m44JpoqsPf5QUj3 Hn5ZDwEC+Be3ioRCZaospDwhSuqLPqk= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of cmarinas@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739377287; 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: in-reply-to:in-reply-to:references:references; bh=TQHyxxf7U+Q7ArPF2wvkaxK+HZ9Xg/0EjkAQ4iTH/Mw=; b=ZuwUkwtQm64GU4xYkVyJBibSk7C0FAe3Sp3ATLAoXCj+b8PaKE+WJLPd4oSWQl5kxRmiTS l/OAWmiQuhYh9IAfjdKvoy2Dwi6M9jey3b1kcagxyXzWK1ikCQBj1QqhvaUytSznl8pTxL r4U3d2b2cPiM56FcnJluNjOclHVd9zs= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id CFDD8A40C23; Wed, 12 Feb 2025 16:19:40 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC65FC4CEDF; Wed, 12 Feb 2025 16:21:20 +0000 (UTC) Date: Wed, 12 Feb 2025 16:21:18 +0000 From: Catalin Marinas To: Tong Tiangen Cc: Mark Rutland , Jonathan Cameron , Mauro Carvalho Chehab , 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" , Madhavan Srinivasan , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, wangkefeng.wang@huawei.com, Guohanjun Subject: Re: [PATCH v13 2/5] arm64: add support for ARCH_HAS_COPY_MC Message-ID: References: <20241209024257.3618492-1-tongtiangen@huawei.com> <20241209024257.3618492-3-tongtiangen@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241209024257.3618492-3-tongtiangen@huawei.com> X-Stat-Signature: 85zozqytw66sq34dpopdooxscm9qk9rs X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 23FB440006 X-Rspam-User: X-HE-Tag: 1739377286-613484 X-HE-Meta: U2FsdGVkX19XmPNwsxubIO2jbhkkrhfqaHb5wIPHylS9pkJL1KPoGBNFDap0virz/Q2wInbvshMi7E4FwfWbZJshFHYt+BEWdW5FtQ5La3o0Ds4tAt7xZLKpxAWs1cyCCBkHFwtl++7l+Ogf7Yn3SwDccuffnxSL6CaAAGKmqoWX9sHzld5TFWdq6kJn2OlA30hkLEHp++LPuKyVLWVAbNMyBzK4cehl76oSeso7/HuSEF7ANpWh8z/0S2Y16RqrhcQvmACkd49s3GGtvf8Tqd16BHYuaSeSvEi/N89vqVAzjNB9aWbxMPOO5ZTsY9E/E1WdjezvVE9M0lIxuNHinJVtOX/n9EsuNWAK6hzfR5u8OhrVO7zcS28fjw/xZ1D8jM3bTeho+9iCp7blQZkrk+bCTmvTAvCWXRxE/poW32uQnB+pvqkgHAeqWf4KcFtf2Ut5WXp8g13LsNKII6NIobJKChKcccIQiixYRPaZAzKW1x5MdldQA1HoTyv8mqtvcTZhy957Jh/lmDHkBHeoDavDsL1InZLTGhuMbumw0IIfjI/RuuyMSBPGnCB9X3vaNcccfxN+fs+RA4jn0uLWmpWzPhoG/LQE/xj0KNMCVKqWu1QtHSEYiRzigDy5yqaMYdqms4nkOW8gWU+g94Bc3N/+KXk06BXxb/YTT+0I35kv9Vt5f6pqB8BrEGRaeclxh3NjLWQF4WoN3KMzWwwID5xz5BL4Vn+sfZ+fzRsWoB/21IYP+Zx1HX3n9Zv+Bzyw4Gvoqq0GRsaVL5UYLazj79/hVQ/CM8zkoFbfhUvrJB5HunQ9VCrZ1tdOZK3Ss/9Z3v/9C7DALklfnHv9jBR7BefsP13Uql5D4U8LVSXzl6pQT4Udl7a8AsPkGZL6JFixerk+Yfn7cdPzY3S1aO1WiYT0Fxri38HbQ+Su9TUncnokBOVqpxyDAHaA6icb5fFj6UzIN3PjZyhdA7xBZqK +rtyzg1/ jVbi79TyWBob2SFdjDB/P27PFErfhxdgZwzYmmzIKwSP0vx6KAqN4fb585XKMsIj/dHdIZR6m1yBTrX2L7OsGBZoW4m9RaW+WrvzfQlioqVM05amgVl4F7MEh0dxTOiH2usRqWVFLeECmTseFk5Y1iGR0oqR3TIywilnFRcqVyQ7dqC42tzjY7NM/iCzy2TQmzuAsdcQEWWVRqHAcVXjM39Jc91KfIbRBZDWi/Be8PeWY/tuNKzR3BVfc22aPZsPf0FJ7dFFl06X1/R3obc7NmRlK6kvc8bO8R2d8xglxefGC+jGhie5lqmMvYnRB4Xid9/ayU1AKQ2ZLUb+xF2QN1/eKnysJ8nUORHEe10+5fzANwOb7H5pU29shPis7v83VQkadg4fDb3LELgiwT4uj74d04VnYaZXRedW0nXsCWLJMNnfZt2N08756bOF1kZ3U1nDrpSJCWGflIYD56ZD9Zo68U0/3ENnUDj67 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: (catching up with old threads) On Mon, Dec 09, 2024 at 10:42:54AM +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. I agree that killing the user process and isolating the page is a better choice but I don't see how the latter happens after this patch. Which page would be isolated? > Add new fixup type EX_TYPE_KACCESS_ERR_ZERO_MEM_ERR to identify insn > that can recover from memory errors triggered by access to kernel memory, > and this fixup type is used in __arch_copy_to_user(), This make the regular > copy_to_user() will handle kernel memory errors. Is the assumption that the error on accessing kernel memory is transient? There's no way to isolate the kernel page and also no point in isolating the destination page either. -- Catalin