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 BBB80C47258 for ; Fri, 2 Feb 2024 07:51:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE53B6B0072; Fri, 2 Feb 2024 02:51:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E95C76B0074; Fri, 2 Feb 2024 02:51:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D5D9C6B0075; Fri, 2 Feb 2024 02:51:22 -0500 (EST) 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 C41E86B0072 for ; Fri, 2 Feb 2024 02:51:22 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5EE4340E96 for ; Fri, 2 Feb 2024 07:51:22 +0000 (UTC) X-FDA: 81746093604.28.547FB2B Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by imf03.hostedemail.com (Postfix) with ESMTP id D402A20005 for ; Fri, 2 Feb 2024 07:51:18 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf03.hostedemail.com: domain of tongtiangen@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=tongtiangen@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706860280; 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=z/KaXJk7mmq8z6dCSVgKQUdpr7fy0PVLmWDSvCQxP94=; b=m9r63SYnh+q17YywRJXUWTq1TRzFupa5CaPMOp26ktWHGkEJqJAcrdKzgwPGB2bjb8um7I AKYhYLX4uC06iYMKbXfOSxir1QzVjnjLVb79OaD+YwVN36geQqxvlo2oux6JxV2pDJavQb 33FCxUiurusYvrNfkLIkIlQlNfGgnGY= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf03.hostedemail.com: domain of tongtiangen@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=tongtiangen@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706860280; a=rsa-sha256; cv=none; b=svKy66QnF0D5GkJjG9EV6ZZTVMLvKK6G6xvju234FuE4kVrPU697mWeOYafWEdscQMjXfI 5eHhedu7ptx1H13DcbY8UkDOSNwg5Dje+iUPghORzleJ1KJNF9qB96UI/A5MQ5mvJ9MCYR s1afq7U+j25k0t+fscKAfSzKrjQVypA= Received: from mail.maildlp.com (unknown [172.19.163.44]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4TR7Fs67dFz1Q8ZP; Fri, 2 Feb 2024 15:49:21 +0800 (CST) Received: from kwepemm600017.china.huawei.com (unknown [7.193.23.234]) by mail.maildlp.com (Postfix) with ESMTPS id 46058140414; Fri, 2 Feb 2024 15:51:14 +0800 (CST) Received: from [10.174.179.234] (10.174.179.234) by kwepemm600017.china.huawei.com (7.193.23.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Fri, 2 Feb 2024 15:51:13 +0800 Message-ID: <39c1e4d2-b1d0-91ae-595e-1add4698dd7f@huawei.com> Date: Fri, 2 Feb 2024 15:51:12 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0 Subject: Re: [PATCH -next v4 2/3] x86/mce: rename MCE_IN_KERNEL_COPYIN to MCE_IN_KERNEL_COPY_MC To: Borislav Petkov CC: Thomas Gleixner , Ingo Molnar , , Dave Hansen , , "H. Peter Anvin" , Tony Luck , Andy Lutomirski , Peter Zijlstra , Andrew Morton , Naoya Horiguchi , , , , Guohanjun References: <20240111135548.3207437-1-tongtiangen@huawei.com> <20240111135548.3207437-3-tongtiangen@huawei.com> <20240131070258.GGZbnwov0g918F-FGz@fat_crate.local> <3009aadd-69d6-c797-20b4-95cf926b6dd9@huawei.com> <20240201142016.GFZbuooG9CRoK90U2C@fat_crate.local> From: Tong Tiangen In-Reply-To: <20240201142016.GFZbuooG9CRoK90U2C@fat_crate.local> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.234] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemm600017.china.huawei.com (7.193.23.234) X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: D402A20005 X-Stat-Signature: 7ndx5mox9tmwfs9sdqatp8ttyteyd3tg X-HE-Tag: 1706860278-135609 X-HE-Meta: U2FsdGVkX1+ceCGEhn1PrzOxIWUiV0TPnt3SQtDHZoyaKmmmVZRcpCChntVnaHu/Qto2epXXtsbOmfVdp2oWAsGbKX5I0Rw+tWe+jssFxmDkJeUF7SUd7Od55rP+2Gpfc8Gb47ijvES6WLsnD3X9OVJpniLqF2cFPy5X9dv8LvOTWACv4V9SzgE3bXxQ7gdfYqkvNI04lU9YNT+IHKydtyyyVQxFzbqrOO3juc2k/KU9mmd8TdLEJT7P7DxQhHXFHJhNXCK+lgYxTn29Mjo/rQfgdoivsQC78HXDrGVTkuAoCS9zq4XrMdDhFs7q5Ao9T0Pdn3dG+jgZSxY789NSLs29wE7Uh/hyeUbhHRVxq+HAcdMnJSsFKoEulOLT1HGpnZSsBMDoy6g07p5rnqleJnZwn0SFXE21qEKOr3cdApVTairWl61t84/fx4kosRM0NmytS/umSh61n24mLIUZIeKFkCnWVDn/oRKxahRTnm4CAQwtc9LJN1BeJjWI6xLbOwaujMsuktUpEIbKLKB4p79d0B7AA8Uewaw+TCTbsNKBUM/ezidsxAI90jWB47Z+FXL6zpTWhXhruGL2tGpKR7HLmJAK8h4mDliFAs72qTXe9vkJkp/V5I7fh+DEz8nfMIuJ32mUH4zq7mhAgZSwKbrAiqbzBJh19Z66a+uLTrXeLOlRLad2ehmCFozZZ5VIaszpOQdm0mpbQsqZ+otwmN3oK5yb7vOrBpJn6cy9Rr8DxYPkeZuYEJY0Ykj+QMeNHcFAh9aT91zxl06WBlgZ3ERzsvDTlTqT1HUp+klFUaKGF3eReuFVU9tyj4e0G2F+KXcj7nbN5SMVqsPF6WTg8RPNnm5I2So5PKi6uekfuiT6ZOlXCOutUVIYvWDS/3mmXlhT9m8T9BItbyhXfV8+KqvAle+246ifKOCf04Ho66UJDZ3elbJ7r6MMfRX7bDOwAOkGI/S3IoFZ6J1Iwqs Ojoi45Yl Cp5HLAQjnr0l065BLK/y0RHsSwQC4NYVQl2jjuqFdhqJjCPV/Q1CC57bzQcmkdYiIiyAjPVgWWPruYyV2ibh4Mc4TKe2AeeslBTldkc+o1fNjkLO85myJmnIW0Ue2GibT+7Dfo3ONZ0G4pNBRYydwWyX497ThM+5YPf9uQgOD3YFpIUDVoGY120oUZVN9/bn9QrfqW192y22OlyI= 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: 在 2024/2/1 22:20, Borislav Petkov 写道: > On Thu, Feb 01, 2024 at 07:37:25PM +0800, Tong Tiangen wrote: >> 在 2024/1/31 15:02, Borislav Petkov 写道: >>> On Thu, Jan 11, 2024 at 09:55:47PM +0800, Tong Tiangen wrote: >>>> Currently, there are some kernel memory copy scenarios is also mc safe >>>> which use copy_mc_to_kernel() or copy_mc_user_highpage(). >>> >>> Both of those end up in copy_mc_enhanced_fast_string() which does >>> EX_TYPE_DEFAULT_MCE_SAFE. >> >> OK, how about this commit msg change? :) >> >> Currently, there are some kernel memory copy scenarios is also mc safe >> which use copy_mc_to_kernel() or copy_mc_user_highpage(), **both of those >> end up in copy_mc_enhanced_fast_string() or copy_mc_fragile() which does >> EX_TYPE_DEFAULT_MCE_SAFE.** >> >> In these scenarios, posion pages need to be isolated too. Therefore, a >> macro similar to MCE_IN_KERNEL_COPYIN is required. For this reason, we >> can rename MCE_IN_KERNEL_COPYIN to MCE_IN_KERNEL_COPY_MC, the new macro >> can be applied to both user-to-kernel mc safe copy and kernel-to-kernel >> mc safe copy. > > Maybe my question wasn't clear: why is that renaming churn needed at > all? What are you "fixing" here? > > What is the problem that you're encountering which needs fixing? This patch is a prepare patch and the next patch is a fix patch, the complete logic of the two patches is as follows: The problem i'm encountering: ------------------------------- In the x86 mce processing, error_context() setting macro MCE_IN_KERNEL_COPYIN to identify copy from user(user-to-kernel copy) for fixup_type EX_TYPE_UACCESS. Then do_machine_check() uses macro MCE_IN_KERNEL_COPYIN to isolate posion page in memory_failure(). Currently, there are some kernel memory copy scenarios is also mc safe which use copy_mc_to_kernel() or copy_mc_user_highpage(), these kernel- to-kernel copy use fixup_type EX_TYPE_DEFAULT_MCE_SAFE. In these scenarios, posion pages need to be isolated too and the current implementation is to actively call memory_failure_queue() when the copy fails. Calling memory_failure_queue() separately is not a good implementation, call it uniformly in do_machine_check() is more reasonable. Solution: ---------- A macro similar to MCE_IN_KERNEL_COPYIN is required, so we can rename MCE_IN_KERNEL_COPYIN to MCE_IN_KERNEL_COPY_MC, the new macro can be applied to both user-to-kernel mc safe copy and kernel-to-kernel mc safe copy, in error_context()，we can set MCE_IN_KERNEL_COPY_MC for both fixup_type EX_TYPE_UACCESS and EX_TYPE_DEFAULT_MCE_SAFE. Do you think it's clear to say so and then we can merge the two patches to make the complete logic clearer in commit msg ? Many thanks. Tong. > > Thx. >