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 EDC4FC433EF for ; Thu, 5 May 2022 14:33:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E64C6B0073; Thu, 5 May 2022 10:33:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 76CBB6B0074; Thu, 5 May 2022 10:33:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 636546B0075; Thu, 5 May 2022 10:33:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 50EA06B0073 for ; Thu, 5 May 2022 10:33:51 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2C5B921BB4 for ; Thu, 5 May 2022 14:33:51 +0000 (UTC) X-FDA: 79431933462.16.3261BBE Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf14.hostedemail.com (Postfix) with ESMTP id 479A210008E for ; Thu, 5 May 2022 14:33:47 +0000 (UTC) Received: from kwepemi500003.china.huawei.com (unknown [172.30.72.54]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4KvGPg0fVQz1JBgJ; Thu, 5 May 2022 22:32:39 +0800 (CST) Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemi500003.china.huawei.com (7.221.188.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 5 May 2022 22:33:43 +0800 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.2375.24; Thu, 5 May 2022 22:33:41 +0800 Message-ID: <618afddc-7110-d6bd-57a4-b80777d560b6@huawei.com> Date: Thu, 5 May 2022 22:33:41 +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 4/7] arm64: add copy_{to, from}_user to machine check safe To: Catalin Marinas CC: Mark Rutland , James Morse , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Robin Murphy , Dave Hansen , Will Deacon , Alexander Viro , Michael Ellerman , "Benjamin Herrenschmidt" , Paul Mackerras , , "H . Peter Anvin" , , , , , Kefeng Wang , Xie XiuQi , Guohanjun References: <20220420030418.3189040-1-tongtiangen@huawei.com> <20220420030418.3189040-5-tongtiangen@huawei.com> <7da54d72-e5fa-41b5-67ea-a0b084e4c94a@huawei.com> From: Tong Tiangen In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.179.234] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemm600017.china.huawei.com (7.193.23.234) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 479A210008E X-Stat-Signature: 3czimoispa4sxjmdnqbu8s3kwczzqiac X-Rspam-User: Authentication-Results: imf14.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf14.hostedemail.com: domain of tongtiangen@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=tongtiangen@huawei.com X-Rspamd-Server: rspam09 X-HE-Tag: 1651761227-332940 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: 在 2022/5/5 21:41, Catalin Marinas 写道: > On Thu, May 05, 2022 at 02:39:43PM +0800, Tong Tiangen wrote: >> 在 2022/5/4 18:26, Catalin Marinas 写道: >>> On Wed, Apr 20, 2022 at 03:04:15AM +0000, Tong Tiangen wrote: >>>> Add copy_{to, from}_user() to machine check safe. >>>> >>>> If copy fail due to hardware memory error, only the relevant processes are >>>> affected, so killing the user process and isolate the user page with >>>> hardware memory errors is a more reasonable choice than kernel panic. >>> >>> Just to make sure I understand - we can only recover if the fault is in >>> a user page. That is, for a copy_from_user(), we can only handle the >>> faults in the source address, not the destination. >> >> At the beginning, I also thought we can only recover if the fault is in a >> user page. >> After discussion with a Mark[1], I think no matter user page or kernel page, >> as long as it is triggered by the user process, only related processes will >> be affected. According to this >> understanding, it seems that all uaccess can be recovered. >> >> [1]https://patchwork.kernel.org/project/linux-arm-kernel/patch/20220406091311.3354723-6-tongtiangen@huawei.com/ > > We can indeed safely skip this copy and return an error just like > pretending there was a user page fault. However, my point was more > around the "isolate the user page with hardware memory errors". If the > fault is on a kernel address, there's not much you can do about. You'll > likely trigger it later when you try to access that address (maybe it > was freed and re-allocated). Do we hope we won't get the same error > again on that kernel address? I think the page with memory error will be isolated by memory_failure(), generally, isolation will succeed, if isolate failure(we need to find out why), then maybe the same error will trigger it later. Thanks. >