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 E6743C43334 for ; Mon, 20 Jun 2022 02:05:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 691056B0072; Sun, 19 Jun 2022 22:05:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 63F3D6B0073; Sun, 19 Jun 2022 22:05:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52E646B0074; Sun, 19 Jun 2022 22:05:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 441896B0072 for ; Sun, 19 Jun 2022 22:05:00 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 21CAE608C9 for ; Mon, 20 Jun 2022 02:05:00 +0000 (UTC) X-FDA: 79596971160.09.24D8040 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf03.hostedemail.com (Postfix) with ESMTP id F109120010 for ; Mon, 20 Jun 2022 02:04:58 +0000 (UTC) Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4LRCYm60vHz922d; Mon, 20 Jun 2022 10:01:32 +0800 (CST) Received: from kwepemm600017.china.huawei.com (7.193.23.234) by dggemv703-chm.china.huawei.com (10.3.19.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 20 Jun 2022 10:04:44 +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; Mon, 20 Jun 2022 10:04:43 +0800 Message-ID: <7d50dcb8-8a7c-5735-cd49-ad814fecf641@huawei.com> Date: Mon, 20 Jun 2022 10:04:42 +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 v5 7/8] arm64: add uaccess to machine check safe To: Mark Rutland CC: James Morse , Andrew Morton , Thomas Gleixner , "Ingo Molnar" , Borislav Petkov , Robin Murphy , Dave Hansen , "Catalin Marinas" , Will Deacon , "Alexander Viro" , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , , "H . Peter Anvin" , , , , , Kefeng Wang , Xie XiuQi , Guohanjun References: <20220528065056.1034168-1-tongtiangen@huawei.com> <20220528065056.1034168-8-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: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemm600017.china.huawei.com (7.193.23.234) X-CFilter-Loop: Reflected ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655690699; 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=qyCeRnQ0znFFR5A7u301llgngvfSxWdHhdEht0B66NA=; b=PeL7b7xWaXuh2M6rFYJvfmUF1dUbWeIQiB3myepUtyaww33A48RdfPw4Tsb3hjG0pXEBJe Rda3u13mqN6D5OyqOh17fQU6YwdEiA7ON63gErWl2tl7iyUziS2obXmSe/PqEDx6DSJmNs ykNLxo+Q8MCzzm6lNpBGNoWEq2r25O0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655690699; a=rsa-sha256; cv=none; b=YQwov5Io7vu4VzRXsx7AWfhziAXN0v8FsNFuljqYIUYUJ7mKGamvaCIrfXKKsN+YY8YGKM Sv+utuL3UBkB37+LIRBVh5381hqYm0N0Rr8YoBSfHpkU6SF/692k3ZAQmZQIVtXnc5Nhxh m6aGA2I2ucU3MIOObeakrzdQyb6rmVk= 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.188 as permitted sender) smtp.mailfrom=tongtiangen@huawei.com 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.188 as permitted sender) smtp.mailfrom=tongtiangen@huawei.com X-Rspamd-Server: rspam12 X-Rspam-User: X-Stat-Signature: zxb8unu89bdykfie41asq5jkjfgsooaa X-Rspamd-Queue-Id: F109120010 X-HE-Tag: 1655690698-607577 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/6/18 19:35, Mark Rutland 写道: > On Sat, Jun 18, 2022 at 05:27:45PM +0800, Tong Tiangen wrote: >> >> >> 在 2022/6/17 17:06, Mark Rutland 写道: >>> On Sat, May 28, 2022 at 06:50:55AM +0000, Tong Tiangen wrote: >>>> If user access fail due to hardware memory error, only the relevant >>>> processes are affected, so killing the user process and isolate the >>>> error page with hardware memory errors is a more reasonable choice >>>> than kernel panic. >>>> >>>> Signed-off-by: Tong Tiangen >>> >>>> --- >>>> arch/arm64/lib/copy_from_user.S | 8 ++++---- >>>> arch/arm64/lib/copy_to_user.S | 8 ++++---- >>> >>> All of these changes are to the *kernel* accesses performed as part of copy >>> to/from user, and have nothing to do with userspace, so it does not make sense >>> to mark these as UACCESS. >> >> You have a point. so there is no need to modify copy_from/to_user.S in this >> patch set. > > Cool, thanks. If this patch just has the extable change, that's fine by me. > >>> Do we *actually* need to recover from failues on these accesses? Looking at >>> _copy_from_user(), the kernel will immediately follow this up with a memset() >>> to the same address which will be fatal anyway, so this is only punting the >>> failure for a few instructions. >> >> If recovery success, The task will be killed and there will be no subsequent >> memset(). > > I don't think that's true. > > IIUC per the last patch, in the exception handler we'll apply the fixup then > force a signal. That doesn't kill the task immediately, and we'll return from > the exception handler back into the original context (with the fixup applied). > correct. > The structure of copy_from_user() is > > copy_from_user(to, from, n) { > _copy_from_user(to, from, n) { > res = n; > res = raw_copy_from_user(to, from, n); > if (res) > memset(to + (n - res), 0, res); > } > } > > So when the fixup is applied and res indicates that the copy terminated early, > there is an unconditinal memset() before the fatal signal is handled in the > return to userspace path. correct in this scenario. My idea is also valuable in many other scenarios. > >>> If we really need to recover from certain accesses to kernel memory we should >>> add a new EX_TYPE_KACCESS_ERR_ZERO_MC or similar, but we need a strong >>> rationale as to why that's useful. As things stand I do not beleive it makes >>> sense for copy to/from user specifically. > > [...] > >>>> diff --git a/arch/arm64/mm/extable.c b/arch/arm64/mm/extable.c >>>> index c301dcf6335f..8ca8d9639f9f 100644 >>>> --- a/arch/arm64/mm/extable.c >>>> +++ b/arch/arm64/mm/extable.c >>>> @@ -86,10 +86,10 @@ bool fixup_exception_mc(struct pt_regs *regs) >>>> if (!ex) >>>> return false; >>>> - /* >>>> - * This is not complete, More Machine check safe extable type can >>>> - * be processed here. >>>> - */ >>>> + switch (ex->type) { >>>> + case EX_TYPE_UACCESS_ERR_ZERO: >>>> + return ex_handler_uaccess_err_zero(ex, regs); >>>> + } >>> >>> This addition specifically makes sense to me, so can you split this into a separate patch? >> >> According to my understanding of the above, only the modification of >> extable.c is retained. >> >> So what do you mean which part is made into a separate patch? > > As above, if you just retain the extable.c changes, that's fine by me. Thanks, Tong. > > Thanks, > Mark. > .