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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9956DC433F5 for ; Thu, 5 May 2022 14:33:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1380704AbiEEOh2 (ORCPT ); Thu, 5 May 2022 10:37:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60860 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1353097AbiEEOh0 (ORCPT ); Thu, 5 May 2022 10:37:26 -0400 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5AC665AA67 for ; Thu, 5 May 2022 07:33:46 -0700 (PDT) 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 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. > 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 D5BBDC433F5 for ; Thu, 5 May 2022 14:34:25 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4KvGRh2Jy6z3cBy for ; Fri, 6 May 2022 00:34:24 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=huawei.com (client-ip=45.249.212.255; helo=szxga08-in.huawei.com; envelope-from=tongtiangen@huawei.com; receiver=) Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) (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 4KvGR70Rlrz3bcK for ; Fri, 6 May 2022 00:33:51 +1000 (AEST) 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 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-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/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. > 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 5AFBCC433F5 for ; Thu, 5 May 2022 14:35:35 +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=jw23qsQ4rSgFo3jE9sv5BnU4wh/yWDgA/SQ8tLr7q7w=; b=UO8pTTO38LHFuw S5csJXXWam95PO6grOPwzbhp29XrsxFdVlMkuSYE502vTljOeOiaaSE/k/+GZdihOzYisDp2t9LVP /uC7TwzGz5lJpw4tSoMXtLEcIyqgOaSDS5//j48bRQwrXgSjqz2dy7VPaa2uX8zPLeWUKamE21kmn 2uEIA1dpDkdSGEh/1+lCXdWCB8lK6+eg6173dSyHf0ye30pjLgIcwc5DAJVlzbisci29d5AOrBM8k srP3X2sv1UGhrW5Oicd7zD/M4KNLjJtEmKofwg3kGt4aoWEM7pQu90ubdH2wb8UbLx95Ze+i9Ta+E NArHfXgQe9vWhmH9yH3Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmcYS-00GOxv-3A; Thu, 05 May 2022 14:34:08 +0000 Received: from szxga08-in.huawei.com ([45.249.212.255]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nmcY9-00GOod-5H for linux-arm-kernel@lists.infradead.org; Thu, 05 May 2022 14:33:54 +0000 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: 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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220505_073352_444373_8D52DEBE X-CRM114-Status: GOOD ( 16.49 ) 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 CgrlnKggMjAyMi81LzUgMjE6NDEsIENhdGFsaW4gTWFyaW5hcyDlhpnpgZM6Cj4gT24gVGh1LCBN YXkgMDUsIDIwMjIgYXQgMDI6Mzk6NDNQTSArMDgwMCwgVG9uZyBUaWFuZ2VuIHdyb3RlOgo+PiDl nKggMjAyMi81LzQgMTg6MjYsIENhdGFsaW4gTWFyaW5hcyDlhpnpgZM6Cj4+PiBPbiBXZWQsIEFw ciAyMCwgMjAyMiBhdCAwMzowNDoxNUFNICswMDAwLCBUb25nIFRpYW5nZW4gd3JvdGU6Cj4+Pj4g QWRkIGNvcHlfe3RvLCBmcm9tfV91c2VyKCkgdG8gbWFjaGluZSBjaGVjayBzYWZlLgo+Pj4+Cj4+ Pj4gSWYgY29weSBmYWlsIGR1ZSB0byBoYXJkd2FyZSBtZW1vcnkgZXJyb3IsIG9ubHkgdGhlIHJl bGV2YW50IHByb2Nlc3NlcyBhcmUKPj4+PiBhZmZlY3RlZCwgc28ga2lsbGluZyB0aGUgdXNlciBw cm9jZXNzIGFuZCBpc29sYXRlIHRoZSB1c2VyIHBhZ2Ugd2l0aAo+Pj4+IGhhcmR3YXJlIG1lbW9y eSBlcnJvcnMgaXMgYSBtb3JlIHJlYXNvbmFibGUgY2hvaWNlIHRoYW4ga2VybmVsIHBhbmljLgo+ Pj4KPj4+IEp1c3QgdG8gbWFrZSBzdXJlIEkgdW5kZXJzdGFuZCAtIHdlIGNhbiBvbmx5IHJlY292 ZXIgaWYgdGhlIGZhdWx0IGlzIGluCj4+PiBhIHVzZXIgcGFnZS4gVGhhdCBpcywgZm9yIGEgY29w eV9mcm9tX3VzZXIoKSwgd2UgY2FuIG9ubHkgaGFuZGxlIHRoZQo+Pj4gZmF1bHRzIGluIHRoZSBz b3VyY2UgYWRkcmVzcywgbm90IHRoZSBkZXN0aW5hdGlvbi4KPj4KPj4gQXQgdGhlIGJlZ2lubmlu ZywgSSBhbHNvIHRob3VnaHQgd2UgY2FuIG9ubHkgcmVjb3ZlciBpZiB0aGUgZmF1bHQgaXMgaW4g YQo+PiB1c2VyIHBhZ2UuCj4+IEFmdGVyIGRpc2N1c3Npb24gd2l0aCBhIE1hcmtbMV0sIEkgdGhp bmsgbm8gbWF0dGVyIHVzZXIgcGFnZSBvciBrZXJuZWwgcGFnZSwKPj4gYXMgbG9uZyBhcyBpdCBp cyB0cmlnZ2VyZWQgYnkgdGhlIHVzZXIgcHJvY2Vzcywgb25seSByZWxhdGVkIHByb2Nlc3NlcyB3 aWxsCj4+IGJlIGFmZmVjdGVkLiBBY2NvcmRpbmcgdG8gdGhpcwo+PiB1bmRlcnN0YW5kaW5nLCBp dCBzZWVtcyB0aGF0IGFsbCB1YWNjZXNzIGNhbiBiZSByZWNvdmVyZWQuCj4+Cj4+IFsxXWh0dHBz Oi8vcGF0Y2h3b3JrLmtlcm5lbC5vcmcvcHJvamVjdC9saW51eC1hcm0ta2VybmVsL3BhdGNoLzIw MjIwNDA2MDkxMzExLjMzNTQ3MjMtNi10b25ndGlhbmdlbkBodWF3ZWkuY29tLwo+IAo+IFdlIGNh biBpbmRlZWQgc2FmZWx5IHNraXAgdGhpcyBjb3B5IGFuZCByZXR1cm4gYW4gZXJyb3IganVzdCBs aWtlCj4gcHJldGVuZGluZyB0aGVyZSB3YXMgYSB1c2VyIHBhZ2UgZmF1bHQuIEhvd2V2ZXIsIG15 IHBvaW50IHdhcyBtb3JlCj4gYXJvdW5kIHRoZSAiaXNvbGF0ZSB0aGUgdXNlciBwYWdlIHdpdGgg aGFyZHdhcmUgbWVtb3J5IGVycm9ycyIuIElmIHRoZQo+IGZhdWx0IGlzIG9uIGEga2VybmVsIGFk ZHJlc3MsIHRoZXJlJ3Mgbm90IG11Y2ggeW91IGNhbiBkbyBhYm91dC4gWW91J2xsCj4gbGlrZWx5 IHRyaWdnZXIgaXQgbGF0ZXIgd2hlbiB5b3UgdHJ5IHRvIGFjY2VzcyB0aGF0IGFkZHJlc3MgKG1h eWJlIGl0Cj4gd2FzIGZyZWVkIGFuZCByZS1hbGxvY2F0ZWQpLiBEbyB3ZSBob3BlIHdlIHdvbid0 IGdldCB0aGUgc2FtZSBlcnJvcgo+IGFnYWluIG9uIHRoYXQga2VybmVsIGFkZHJlc3M/CgpJIHRo aW5rIHRoZSBwYWdlIHdpdGggbWVtb3J5IGVycm9yIHdpbGwgYmUgaXNvbGF0ZWQgYnkgbWVtb3J5 X2ZhaWx1cmUoKSwgCmdlbmVyYWxseSwgaXNvbGF0aW9uIHdpbGwgc3VjY2VlZCwgaWYgaXNvbGF0 ZSBmYWlsdXJlKHdlIG5lZWQgdG8gZmluZCAKb3V0IHdoeSksIHRoZW4gbWF5YmUgdGhlIHNhbWUg ZXJyb3Igd2lsbCB0cmlnZ2VyIGl0IGxhdGVyLgoKVGhhbmtzLgoKPiAKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxpbnV4LWFybS1rZXJuZWwgbWFpbGlu ZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZwpodHRwOi8vbGlzdHMu aW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LWFybS1rZXJuZWwK