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 A09E4C77B7C for ; Fri, 26 May 2023 07:10:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1886D900004; Fri, 26 May 2023 03:10:03 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 138B0900002; Fri, 26 May 2023 03:10:03 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0006B900004; Fri, 26 May 2023 03:10:02 -0400 (EDT) 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 E223E900002 for ; Fri, 26 May 2023 03:10:02 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A41F5140D57 for ; Fri, 26 May 2023 07:10:02 +0000 (UTC) X-FDA: 80831531844.30.36F86F2 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by imf07.hostedemail.com (Postfix) with ESMTP id 99F2A4000C for ; Fri, 26 May 2023 07:10:00 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none ("invalid DKIM record") header.d=alien8.de header.s=dkim header.b=EANCxojI; spf=pass (imf07.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685085001; a=rsa-sha256; cv=none; b=O6UDC2hV5pW5J1paF4LWjSI0Y7HAPQEESX6Kzn+1p5vL0Ol1DaYkxvy6DYO5IMAqTN3LVf N/IdJYj6Zy7X1KoCazAwHgEAkIvsRrKwLHuxWm2eBsnwdVywz9vZp4yMbXlSv5Pu5XUXEu csexCren2eYorPfZLNWIyWT8GjKEOzE= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none ("invalid DKIM record") header.d=alien8.de header.s=dkim header.b=EANCxojI; spf=pass (imf07.hostedemail.com: domain of bp@alien8.de designates 5.9.137.197 as permitted sender) smtp.mailfrom=bp@alien8.de; dmarc=pass (policy=none) header.from=alien8.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1685085001; 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:dkim-signature; bh=X0HHCOKK04/WfityQLFv+JuVRYYiZi/UhC8LKgTBpNY=; b=A/0yK5qdhHn8cy1UR8Lst8qaJQP0jPiwMkRg27tQ5hFFeH90IypkQdQultPSZLVlF3Kmdg T34fgMw6RFeDIONNaR++sMd/7kcsEeiCBmjckLE/a3sDT3BBxjluCJ3JDViEN23ZRqAnDB d69IZy35koHV/UtbEz9Q1XJc95f+GKQ= Received: from nazgul.tnic (dynamic-002-247-249-230.2.247.pool.telefonica.de [2.247.249.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 4D6791EC0657; Fri, 26 May 2023 09:09:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1685084998; h=from:from: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=X0HHCOKK04/WfityQLFv+JuVRYYiZi/UhC8LKgTBpNY=; b=EANCxojIMfk+AAnld7m3n8Ja/AKbU02hdMkccAVhxEqzvAeUXPhyvo1G0Nf78LGcTEADaQ 6OOQKSpr7YkmvyuzhOv4hp64XVntYHlFsjR2vdPGvfTybxySc8NVjOSuiLTn2uKDzMtFi5 7bH/z0ghcUYDdl3oYa9kN8+9cvYcZK8= Date: Fri, 26 May 2023 09:09:52 +0200 From: Borislav Petkov To: Kefeng Wang Cc: tony.luck@intel.com, naoya.horiguchi@nec.com, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, akpm@linux-foundation.org, linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, jane.chu@oracle.com Subject: Re: [PATCH v2] x86/mce: set MCE_IN_KERNEL_COPYIN for all MC-Safe Copy Message-ID: <20230526070952.GAZHBbQNAWZJP6tOXv@nazgul.local> References: <20230526063242.133656-1-wangkefeng.wang@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20230526063242.133656-1-wangkefeng.wang@huawei.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 99F2A4000C X-Stat-Signature: igfnt4mmft3rpe18uwfydu6d97phj1yi X-Rspam-User: X-HE-Tag: 1685085000-166101 X-HE-Meta: U2FsdGVkX18x31eAt6YHT38y+PfffYaG8lVxZ9abphoL2NGc2u3XI8d8pxOcwG6dQujwVdAIx7IxKevThyU5mNF75RmdO0nw8LY6JMzkeZRg5gnkuID7sD+7n8syLbOSNU1ELWwbq8kttdtXEIHZbUnL5DuU4neHCklFblNQUgil4GQRaw79rSXUWUyVrjCgJYb+qLmHhmzOeOCh6N199MvT9OCrrJhm5r6LBzEqTg8Auv6EBhgL5FpOqyMtHo0xUxRLFP7AvHUhD2o44frrs4RNGOYbCK+I0DTxmB2DIktzv7nUF8kbdXE7hGjzovOAKyit05Cha5ecyB04ZjGwwAZC5FlO6nUyuZ3SJYVwMOj8MxYXY3S+8uwrQSLIDEWSr74Z01pKpKWz0I5UF7BXJc5mYo0yNetOlIxGBZOueNkEEdkDwLdL/lQpXYhNlHnGc4nfoCJNT5x6oLKnWW/gk89lklknTAOvwdrb+2ostFjpT+6BdrYtv12gYInobO3dlzk58/oRBmrUrJz8X0CCiWX9fvuTyuVqdr4wSAudyww+rdmEtAlk2FhP+PBq7ulm7DXBLT00JMhULSJULxDNyHVZhT/dzCsh5MGO8aERWBorwqUkX7cNWFZAOGukkc5RwKKNSOfYIOyM6BG/nKCKMiaM9KTfruiw5SiadRFt9+2SCELlqC6fCqBYfswJNLFD8pEImRGRMnxhy1+buJ44wNmaM/oplBezoVzg39PFzwB+vLSWSzgk1dDVLwXA6SiuCPx0dzc1TFW75lJfGiSgDNhl0m6bPAqBKM86CStq3ts/pNU/nZkLqazNIaCJMgE/gNP8CiXOq9n+GJ7QwiU0e5TNIDeppKwX90NqkuXjo1zHerB4Naq2ARYU2NJxEMmNp9srQhsyMXUU7XYvoqgIHe6EpCb8opX69zixy1SMiibTLMpB7wKO7uF2PvRQrr6wmYMToywh9HDr9/y++w6 UzJK54LI C0RycHslfp6nNWj8lTuhx1rGAMfaqtet6/Ma3VylsVgdtOK1cr37TfS2qpn2RjKvzenErdgKiQAUGndJ80UcNOFA/S5Po2WGt87ms1NTEQJXxBhOTCAG6O5ki7ctZ8bEK2xSzycVutywueXeQt8d3laJOE1mRhB6BWwIBJzUyBLgQp1TTc8adnSpwqNimemIqBohZ2Bm2mbvyhCAmIUbITnNDqpDrzlG2QiBxOoOW2rIDc7kG95mzTTxgqw== 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 Fri, May 26, 2023 at 02:32:42PM +0800, Kefeng Wang wrote: > The best way to fix them is set MCE_IN_KERNEL_COPYIN for MC-Safe Copy, > then let the core do_machine_check() to isolate corrupted page instead > of doing it one-by-one. No, this whole thing is confused. * Indicates an MCE that happened in kernel space while copying data * from user. #define MCE_IN_KERNEL_COPYIN This is a very specific exception type: EX_TYPE_COPY which got added by 278b917f8cb9 ("x86/mce: Add _ASM_EXTABLE_CPY for copy user access") but Linus then removed all such user copy exception points in 034ff37d3407 ("x86: rewrite '__copy_user_nocache' function") So now that EX_TYPE_COPY never happens. And what you're doing is lumping the handling for EX_TYPE_DEFAULT_MCE_SAFE and EX_TYPE_FAULT_MCE_SAFE together and saying that the MCE happened while copying data from user. And XSTATE_OP() is one example where this is not really the case. So no, this is not correct. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette