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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 09E25C433F5 for ; Thu, 5 May 2022 06:40:30 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4Kv3ws1zq6z3c8F for ; Thu, 5 May 2022 16:40:29 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=huawei.com (client-ip=45.249.212.189; helo=szxga03-in.huawei.com; envelope-from=tongtiangen@huawei.com; receiver=) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4Kv3wL4Yrmz2yb9 for ; Thu, 5 May 2022 16:39:58 +1000 (AEST) Received: from kwepemi500023.china.huawei.com (unknown [172.30.72.55]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4Kv3pc69TXzDqKY; Thu, 5 May 2022 14:35:04 +0800 (CST) Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemi500023.china.huawei.com (7.221.188.76) 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 14:39:45 +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 14:39:44 +0800 Message-ID: <7da54d72-e5fa-41b5-67ea-a0b084e4c94a@huawei.com> Date: Thu, 5 May 2022 14:39:43 +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 References: <20220420030418.3189040-1-tongtiangen@huawei.com> <20220420030418.3189040-5-tongtiangen@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: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemm600017.china.huawei.com (7.193.23.234) X-CFilter-Loop: Reflected X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Kefeng Wang , Dave Hansen , linux-mm@kvack.org, Paul Mackerras , Guohanjun , Will Deacon , "H . Peter Anvin" , x86@kernel.org, Ingo Molnar , Xie XiuQi , Borislav Petkov , Alexander Viro , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Robin Murphy , linux-kernel@vger.kernel.org, James Morse , Andrew Morton , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" 在 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/ Thanks, Tong. > >> diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S >> index 34e317907524..480cc5ac0a8d 100644 >> --- a/arch/arm64/lib/copy_from_user.S >> +++ b/arch/arm64/lib/copy_from_user.S >> @@ -25,7 +25,7 @@ >> .endm >> >> .macro strb1 reg, ptr, val >> - strb \reg, [\ptr], \val >> + USER_MC(9998f, strb \reg, [\ptr], \val) >> .endm > > So if I got the above correctly, why do we need an exception table entry > for the store to the kernel address? > 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 95BEFC433EF for ; Thu, 5 May 2022 06:41:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:CC:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=d74MVdI79Hm23F9vAinV6mHruQN472Ws+sAP93O7hVs=; b=V1d4jyIV15619O K2UJZQ9ng6cquVDoD8nklBLmZBZ36vHa5alC7LGXG3QT0RHYTJOi2mZ3xPApThQiekhhunStZeD04 nkMthLr+4648T1zJHAfSCaFUzJMgdGwMnaOs98roELWYYh0JksKfUkKJFlkP/rgQ8UxJQbDuUNdcN T0h3HS0MDtNE7T/13mIbg1SxUMKeCl3FcdqvVGltEc+dPxx09Qj9ihVJDcw4Y4BDj+D3uxXvLU2hd WVYiM5LAClgMN3XIuuvRL4iwOAHUfah8p+kWg6UwsG2PZQ9w8E54HvTCZKRIt/Dv3hs65M8RvEvtZ 1a7XdKxgKB1tTVOqpz8Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmV9c-00EFSt-UV; Thu, 05 May 2022 06:40:01 +0000 Received: from szxga03-in.huawei.com ([45.249.212.189]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmV9Y-00EFPe-OX for linux-arm-kernel@lists.infradead.org; Thu, 05 May 2022 06:39:58 +0000 Received: from kwepemi500023.china.huawei.com (unknown [172.30.72.55]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4Kv3pc69TXzDqKY; Thu, 5 May 2022 14:35:04 +0800 (CST) Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemi500023.china.huawei.com (7.221.188.76) 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 14:39:45 +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 14:39:44 +0800 Message-ID: <7da54d72-e5fa-41b5-67ea-a0b084e4c94a@huawei.com> Date: Thu, 5 May 2022 14:39:43 +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> From: Tong Tiangen In-Reply-To: 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-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220504_233957_079426_56600D8E X-CRM114-Status: GOOD ( 12.36 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org CgrlnKggMjAyMi81LzQgMTg6MjYsIENhdGFsaW4gTWFyaW5hcyDlhpnpgZM6Cj4gT24gV2VkLCBB cHIgMjAsIDIwMjIgYXQgMDM6MDQ6MTVBTSArMDAwMCwgVG9uZyBUaWFuZ2VuIHdyb3RlOgo+PiBB ZGQgY29weV97dG8sIGZyb219X3VzZXIoKSB0byBtYWNoaW5lIGNoZWNrIHNhZmUuCj4+Cj4+IElm IGNvcHkgZmFpbCBkdWUgdG8gaGFyZHdhcmUgbWVtb3J5IGVycm9yLCBvbmx5IHRoZSByZWxldmFu dCBwcm9jZXNzZXMgYXJlCj4+IGFmZmVjdGVkLCBzbyBraWxsaW5nIHRoZSB1c2VyIHByb2Nlc3Mg YW5kIGlzb2xhdGUgdGhlIHVzZXIgcGFnZSB3aXRoCj4+IGhhcmR3YXJlIG1lbW9yeSBlcnJvcnMg aXMgYSBtb3JlIHJlYXNvbmFibGUgY2hvaWNlIHRoYW4ga2VybmVsIHBhbmljLgo+IAo+IEp1c3Qg dG8gbWFrZSBzdXJlIEkgdW5kZXJzdGFuZCAtIHdlIGNhbiBvbmx5IHJlY292ZXIgaWYgdGhlIGZh dWx0IGlzIGluCj4gYSB1c2VyIHBhZ2UuIFRoYXQgaXMsIGZvciBhIGNvcHlfZnJvbV91c2VyKCks IHdlIGNhbiBvbmx5IGhhbmRsZSB0aGUKPiBmYXVsdHMgaW4gdGhlIHNvdXJjZSBhZGRyZXNzLCBu b3QgdGhlIGRlc3RpbmF0aW9uLgoKQXQgdGhlIGJlZ2lubmluZywgSSBhbHNvIHRob3VnaHQgd2Ug Y2FuIG9ubHkgcmVjb3ZlciBpZiB0aGUgZmF1bHQgaXMgaW4gCmEgdXNlciBwYWdlLgpBZnRlciBk aXNjdXNzaW9uIHdpdGggYSBNYXJrWzFdLCBJIHRoaW5rIG5vIG1hdHRlciB1c2VyIHBhZ2Ugb3Ig a2VybmVsIApwYWdlLCBhcyBsb25nIGFzIGl0IGlzIHRyaWdnZXJlZCBieSB0aGUgdXNlciBwcm9j ZXNzLCBvbmx5IHJlbGF0ZWQgCnByb2Nlc3NlcyB3aWxsIGJlIGFmZmVjdGVkLiBBY2NvcmRpbmcg dG8gdGhpcwp1bmRlcnN0YW5kaW5nLCBpdCBzZWVtcyB0aGF0IGFsbCB1YWNjZXNzIGNhbiBiZSBy ZWNvdmVyZWQuCgpbMV1odHRwczovL3BhdGNod29yay5rZXJuZWwub3JnL3Byb2plY3QvbGludXgt YXJtLWtlcm5lbC9wYXRjaC8yMDIyMDQwNjA5MTMxMS4zMzU0NzIzLTYtdG9uZ3RpYW5nZW5AaHVh d2VpLmNvbS8KClRoYW5rcywKVG9uZy4KCj4gCj4+IGRpZmYgLS1naXQgYS9hcmNoL2FybTY0L2xp Yi9jb3B5X2Zyb21fdXNlci5TIGIvYXJjaC9hcm02NC9saWIvY29weV9mcm9tX3VzZXIuUwo+PiBp bmRleCAzNGUzMTc5MDc1MjQuLjQ4MGNjNWFjMGE4ZCAxMDA2NDQKPj4gLS0tIGEvYXJjaC9hcm02 NC9saWIvY29weV9mcm9tX3VzZXIuUwo+PiArKysgYi9hcmNoL2FybTY0L2xpYi9jb3B5X2Zyb21f dXNlci5TCj4+IEBAIC0yNSw3ICsyNSw3IEBACj4+ICAgCS5lbmRtCj4+ICAgCj4+ICAgCS5tYWNy byBzdHJiMSByZWcsIHB0ciwgdmFsCj4+IC0Jc3RyYiBccmVnLCBbXHB0cl0sIFx2YWwKPj4gKwlV U0VSX01DKDk5OThmLCBzdHJiIFxyZWcsIFtccHRyXSwgXHZhbCkKPj4gICAJLmVuZG0KPiAKPiBT byBpZiBJIGdvdCB0aGUgYWJvdmUgY29ycmVjdGx5LCB3aHkgZG8gd2UgbmVlZCBhbiBleGNlcHRp b24gdGFibGUgZW50cnkKPiBmb3IgdGhlIHN0b3JlIHRvIHRoZSBrZXJuZWwgYWRkcmVzcz8KPiAK Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFy bS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9y ZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1r ZXJuZWwK 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 36D75C433EF for ; Thu, 5 May 2022 06:39:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9AFBA6B0071; Thu, 5 May 2022 02:39:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 939406B0073; Thu, 5 May 2022 02:39:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FFC36B0074; Thu, 5 May 2022 02:39: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 6C8F76B0071 for ; Thu, 5 May 2022 02:39:51 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 4968B2C71B for ; Thu, 5 May 2022 06:39:51 +0000 (UTC) X-FDA: 79430738982.19.FB13054 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by imf25.hostedemail.com (Postfix) with ESMTP id B7695A008E for ; Thu, 5 May 2022 06:39:36 +0000 (UTC) Received: from kwepemi500023.china.huawei.com (unknown [172.30.72.55]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4Kv3pc69TXzDqKY; Thu, 5 May 2022 14:35:04 +0800 (CST) Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemi500023.china.huawei.com (7.221.188.76) 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 14:39:45 +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 14:39:44 +0800 Message-ID: <7da54d72-e5fa-41b5-67ea-a0b084e4c94a@huawei.com> Date: Thu, 5 May 2022 14:39:43 +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> 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: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemm600017.china.huawei.com (7.193.23.234) X-CFilter-Loop: Reflected X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: B7695A008E X-Stat-Signature: ez4735cdjdnwg4u3p1u9enq3t61xjrxp X-Rspam-User: Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of tongtiangen@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=tongtiangen@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-HE-Tag: 1651732776-10690 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/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/ Thanks, Tong. > >> diff --git a/arch/arm64/lib/copy_from_user.S b/arch/arm64/lib/copy_from_user.S >> index 34e317907524..480cc5ac0a8d 100644 >> --- a/arch/arm64/lib/copy_from_user.S >> +++ b/arch/arm64/lib/copy_from_user.S >> @@ -25,7 +25,7 @@ >> .endm >> >> .macro strb1 reg, ptr, val >> - strb \reg, [\ptr], \val >> + USER_MC(9998f, strb \reg, [\ptr], \val) >> .endm > > So if I got the above correctly, why do we need an exception table entry > for the store to the kernel address? >