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 03195C77B7A for ; Fri, 26 May 2023 12:18:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 580C5900004; Fri, 26 May 2023 08:18:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 53119900002; Fri, 26 May 2023 08:18:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F81D900004; Fri, 26 May 2023 08:18:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 26A47900002 for ; Fri, 26 May 2023 08:18:19 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id F2B2A140E73 for ; Fri, 26 May 2023 12:18:18 +0000 (UTC) X-FDA: 80832308676.02.917CA01 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf01.hostedemail.com (Postfix) with ESMTP id 4896A40013 for ; Fri, 26 May 2023 12:18:14 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf01.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685103496; a=rsa-sha256; cv=none; b=NOJIfpyMecNLZw1p3V5PkAOvDuLErotAcKE6NnVhSQdJaTFHDt9C/64sIQqiv/Gql/wEBt S5m+cuQ7sZfuKH3tOiedWcjWYkQu4/g0aSokE36u+8Kbyw4Kau9vhMvG3hQRorSQCflMm0 Dl1B+6xm70DQ9r1A/Bq+XW0rt+pOIyA= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf01.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1685103496; 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=eToAeMANqbuVN1xQdQlNQ1WKbkqFJZ6a73fbvP0J32U=; b=UE5t2n1/HovZB+WnaOCMfWmY8uJAmQxM1pSbbtxjxM8HXNd+wP0zftbYB1aUW7D6czZVht FKzoqVPPxl1cm6JlD5W+9+6A3KA683MV5R+E8DTYCZbpfclbf3aMg2ujkR5hLxoW+U2WkT JN22Zocu4qxqdSCJmxa8XqUBB5LbS+I= Received: from dggpemm500001.china.huawei.com (unknown [172.30.72.54]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4QSP362Jwlz18LbC; Fri, 26 May 2023 20:13:38 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Fri, 26 May 2023 20:18:09 +0800 Message-ID: Date: Fri, 26 May 2023 20:18:09 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: [PATCH v2] x86/mce: set MCE_IN_KERNEL_COPYIN for all MC-Safe Copy Content-Language: en-US To: Borislav Petkov , Youquan Song CC: , , , , , , , , , , References: <20230526063242.133656-1-wangkefeng.wang@huawei.com> <20230526070952.GAZHBbQNAWZJP6tOXv@nazgul.local> From: Kefeng Wang In-Reply-To: <20230526070952.GAZHBbQNAWZJP6tOXv@nazgul.local> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500001.china.huawei.com (7.185.36.107) X-CFilter-Loop: Reflected X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 4896A40013 X-Stat-Signature: z1bjjmw9eu8b1mbpnpmaknmchbtk1pae X-Rspam-User: X-HE-Tag: 1685103494-974226 X-HE-Meta: U2FsdGVkX1/bA922kIthEKJkX6xI4bGtdq3ak2sq4cVVldQOtXd+C1wSstTMDf/gxAiLJ+I4VH/Py3k87WzEKqy3GjJCJzJIB+VEPhdbItmhq1ZrekMrcffsu3KUtGg7QVhITSFjiWIZvbvqKLIwrzaNfhXvOeWPpQe2LgjvMPSreejimSWG9cuOwzu83Nfs9AOC5sqx2LPSud+NgoG8Z13a/F6Xc284Hz44ydYcoiRSaud4hRUZQGrVwWH5f3ZWezMRBePy0N06EQKi4NrN/cirCxlwXGUPkTec7xvKTeRfISDjbQpWvWkQRNR/p7N2dlQeGc3nFW1fDr1f0oDZdLVgaQJ1UEFYk8lv5uZUAzeYKRDaBfcucSwnuTeAOlG83onrxOSm8DnBSMC9wlMXSPonQg3IqmWTVgOQ15MBwgifi+JcwcKy1B8WAd7KAYhf2keB+ozRRI2S7+ppQiPLnmGC6wRaSFnJr1LA/DJcRVjfv+QhXszPiK6BGXod+8lJYqPSF4a524n1TH4Iedt942u9xcc+s2F6iZgh//SyWJnWR9I0rLGQAH67LOYAJ5QkC5TrJD/8RgwXysTH868jsHiANUc6VvxR2HZLU2I5kIrapeXtryKKmNMdFMvA0aYk5DZtw9N6xBUNfwWfOHl3M41SLO1ukw1kMDgXoxACCkOrBX72VjaARogfdE3d0YeX2+XfaCkoWJ+yVXKiVAoOiuApZsEm3B/MWaobVRnaeUY75bzBNXUPdjzDK6SWGMrSTUIk2I0Ivq6sW9rhcRTiOFhokluCY7FAxqLenAU1y2IIl1OEPi4/8nsUL2vSB8i/age/eWSuHL/gt253xWizCZNAIQp5xIQ0RNk+OF2J4SCcLx9OXmT/pR0DJaD2tciLdsfjH/MCXX3nmyLF+yUSMwX/4QmKhcrVP1YRHECP6d/orAJszxPTBhbP6wV3nnaGoyg+SwY4hd6cKyebHD3 gTJ/QjEB aVcgOujHtf8jYyN+ZmfztHusWgULlsOe6uhDWTPx79ROZtuwCyB21Z3fHiYLpZzpf+KkkwL7XcUWl9OA64nFEqO6ux/+s79tGzllmKmHLJ2q9RG0pk0wTTtqJQrSSMP6kBTsf9YCmFnUkTT/3i5OxmePgzU+5pNwH26p3CkIEEFDGPRlCzuFbgxdUzQ== 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 2023/5/26 15:09, Borislav Petkov wrote: > 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. Is this broken the recover when kernel was copying from user space? + Youquan could you help to check it? > > 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. > Oh, for XSTATE_OP(), it uses EX_TYPE_DEFAULT_MCE_SAFE, but I'm focus on EX_TYPE_DEFAULT_MCE_SAFE, which use copy_mc (arch/x86/lib/copy_mc_64.S), like I maintained in changelog, CoW/Coredump/nvdimm/dax, they use copy_mc_xxx function, sorry for mixed them up. > So no, this is not correct. so only add MCE_IN_KERNEL_COPYIN for EX_TYPE_DEFAULT_MCE_SAFE? diff --git a/arch/x86/kernel/cpu/mce/severity.c b/arch/x86/kernel/cpu/mce/severity.c index c4477162c07d..6d2587994623 100644 --- a/arch/x86/kernel/cpu/mce/severity.c +++ b/arch/x86/kernel/cpu/mce/severity.c @@ -293,11 +293,11 @@ static noinstr int error_context(struct mce *m, struct pt_regs *regs) case EX_TYPE_COPY: if (!copy_user) return IN_KERNEL; + fallthrough; + case EX_TYPE_DEFAULT_MCE_SAFE: m->kflags |= MCE_IN_KERNEL_COPYIN; fallthrough; - case EX_TYPE_FAULT_MCE_SAFE: - case EX_TYPE_DEFAULT_MCE_SAFE: m->kflags |= MCE_IN_KERNEL_RECOV; return IN_KERNEL_RECOV; Correct me if I am wrong, thanks for you reviewing. >