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 12527C433EF for ; Mon, 20 Jun 2022 01:53:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 664C16B0072; Sun, 19 Jun 2022 21:53:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C7ED6B0073; Sun, 19 Jun 2022 21:53:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 466D56B0074; Sun, 19 Jun 2022 21:53:34 -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 3027C6B0072 for ; Sun, 19 Jun 2022 21:53:34 -0400 (EDT) Received: from smtpin31.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 0987A604C8 for ; Mon, 20 Jun 2022 01:53:34 +0000 (UTC) X-FDA: 79596942348.31.A37FBC0 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf28.hostedemail.com (Postfix) with ESMTP id C0735C0012 for ; Mon, 20 Jun 2022 01:53:32 +0000 (UTC) Received: from dggemv703-chm.china.huawei.com (unknown [172.30.72.57]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4LRCLb5QCdzkWMc; Mon, 20 Jun 2022 09:51:51 +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 09:53:29 +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 09:53:27 +0800 Message-ID: <95ae5d1a-fcfd-9106-4b13-9978de1a3d23@huawei.com> Date: Mon, 20 Jun 2022 09:53:26 +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 6/8] arm64: add support for machine check error 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-7-tongtiangen@huawei.com> <4aa8b109-c79b-8da0-db89-85ca128f1049@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: dggems702-chm.china.huawei.com (10.3.19.179) To kwepemm600017.china.huawei.com (7.193.23.234) X-CFilter-Loop: Reflected ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655690013; a=rsa-sha256; cv=none; b=lf+cpxZtqlggOt1o+r3FYYcZ9ESemL9746b/r4LiuxmcqkeVKJqiq7/lLiGiLiGF3QV2iF WMzei7irJyeWghPGLoVNWo/rhu1sZz2mOtLL28deVIHQ6YwGZrJaivcER7xY4iyo1ivAH4 Z8Ol/hkiFO4ABZM4M0tFPCQglBKsNGs= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf28.hostedemail.com: domain of tongtiangen@huawei.com designates 45.249.212.188 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=1655690013; 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=prOq3udDUBRxaxJVT8va6P/2GlTJJNRYqOPB4W5ZLwU=; b=nM/CIi3XyD9v0H82of6jdSma5XWrHCzgr/UgZufkjfq1wyHZjdLPvLkOUP3raN8aYsfitN 4y/Ok2nVVWWyR2NmUbLl6HfP/o4IP+eoYQ6DM5xTACGj/gRTv20cw6rTwftUOPGXKxSx2m rF9awksgKLmOc0qyHdOtWYqz1NsdOuM= Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf28.hostedemail.com: domain of tongtiangen@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=tongtiangen@huawei.com X-Stat-Signature: c88gd18ek14aeha7zwmojat88r7ygzof X-Rspamd-Queue-Id: C0735C0012 X-Rspam-User: X-Rspamd-Server: rspam03 X-HE-Tag: 1655690012-119252 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 20:52, Mark Rutland 写道: > On Sat, Jun 18, 2022 at 05:18:55PM +0800, Tong Tiangen wrote: >> 在 2022/6/17 16:55, Mark Rutland 写道: >>> On Sat, May 28, 2022 at 06:50:54AM +0000, Tong Tiangen wrote: >>>> +static bool arm64_do_kernel_sea(unsigned long addr, unsigned int esr, >>>> + struct pt_regs *regs, int sig, int code) >>>> +{ >>>> + if (!IS_ENABLED(CONFIG_ARCH_HAS_COPY_MC)) >>>> + return false; >>>> + >>>> + if (user_mode(regs) || !current->mm) >>>> + return false; >>> >>> What's the `!current->mm` check for? >> >> At first, I considered that only user processes have the opportunity to >> recover when they trigger memory error. >> >> But it seems that this restriction is unreasonable. When the kernel thread >> triggers memory error, it can also be recovered. for instance: >> >> https://lore.kernel.org/linux-mm/20220527190731.322722-1-jiaqiyan@google.com/ >> >> And i think if(!current->mm) shoud be added below: >> >> if(!current->mm) { >> set_thread_esr(0, esr); >> arm64_force_sig_fault(...); >> } >> return true; > > Why does 'current->mm' have anything to do with this, though? Sorry, typo, my original logic was: if(current->mm) { [...] } > > There can be kernel threads with `current->mm` set in unusual circumstances > (and there's a lot of kernel code out there which handles that wrong), so if > you want to treat user tasks differently, we should be doing something like > checking PF_KTHREAD, or adding something like an is_user_task() helper. > OK, i do want to treat user tasks differently here and didn't take into account what you said. will be fixed next version according to your suggestiong. As follows: if (!(current->flags & PF_KTHREAD)) { set_thread_esr(0, esr); arm64_force_sig_fault(...); } return true; > [...] > >>>> + >>>> + if (apei_claim_sea(regs) < 0) >>>> + return false; >>>> + >>>> + if (!fixup_exception_mc(regs)) >>>> + return false; >>> >>> I thought we still wanted to signal the task in this case? Or do you expect to >>> add that into `fixup_exception_mc()` ? >> >> Yeah, here return false and will signal to task in do_sea() -> >> arm64_notify_die(). > > I mean when we do the fixup. > > I thought the idea was to apply the fixup (to stop the kernel from crashing), > but still to deliver a fatal signal to the user task since we can't do what the > user task asked us to. > Yes, that's what i mean. :) >>>> + >>>> + set_thread_esr(0, esr); >>> >>> Why are we not setting the address? Is that deliberate, or an oversight? >> >> Here set fault_address to 0, i refer to the logic of arm64_notify_die(). >> >> void arm64_notify_die(...) >> { >> if (user_mode(regs)) { >> WARN_ON(regs != current_pt_regs()); >> current->thread.fault_address = 0; >> current->thread.fault_code = err; >> >> arm64_force_sig_fault(signo, sicode, far, str); >> } else { >> die(str, regs, err); >> } >> } >> >> I don't know exactly why and do you know why arm64_notify_die() did this? :) > > To be honest, I don't know, and that looks equally suspicious to me. > > Looking at the git history, that was added in commit: > > 9141300a5884b57c ("arm64: Provide read/write fault information in compat signal handlers") > > ... so maybe Catalin recalls why. > > Perhaps the assumption is just that this will be fatal and so unimportant? ... > but in that case the same logic would apply to the ESR value, so it's not clear > to me. OK, let's proceed as set to 0, if there is any change later, the two positions shall be changed together. Thanks, Tong. > > Mark. > > .