Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp564363ybz; Wed, 15 Apr 2020 14:07:19 -0700 (PDT) X-Google-Smtp-Source: APiQypKvcoJnoango1gkbqQXxK2ePRPR8BEsK6pUL+gvNw+0UH6hEgqt2leJ1Bgc9zx7K6nKYz5T X-Received: by 2002:a17:906:2988:: with SMTP id x8mr6688900eje.16.1586984839780; Wed, 15 Apr 2020 14:07:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586984839; cv=none; d=google.com; s=arc-20160816; b=KhSY7IRMzDbWOZw+xQqNZSSKhNx8iT9zrwcoOE/hHVrYjQNVH1ws3OE7n/KgkqVPxo LJwwr9/Rs1AY1Rr8ykKCZ8POpae5qD6hqLR8s8/5feEK7Ry+uDIIawMJ4mEh8bhBgfT7 o5y/JufNdMGkL3w4+JVQpm754y61UJ8oBz9hn4uRHkS3koiKCaXG+paTjZV5Ed4dJRAl aw6674kfpCuZJWhZkog/5fHJkTeDiR9sKcaP5z+UbyO7ZrjkzYxU5fI6fh/NyQkQwTd7 Z4ID4IyvapvWSrGX8UBdVs0HLKSlPiOnKN6BGqjvL9Egsj+SABNBoSEDakyRCCEQ6Z3x DbtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=wcs0sszE9l4IhbB4FOzhlN0jIBwJhAbZTVVvTDB7iTs=; b=ZsSr6491YYp8byPftw4qieHbxR/2kaKNabQUg7XbIqlA94742PFKll8WgjkrYlr084 V0yEQ3pLa8IhtsFB6QMNPJ8FXk5qjtr+oQc9bJS1W9ncYQUjK0LjvcmOjE5/z2weWv2O HMm98XVlNRGXNvX7pd3hASzshBcZjA5l7vrXTOGW67OEiXGsOOiI7Zbw6fOX2LHaxLnk Bza6+6cF59vjJhAgNZU/Vo3dQ1OcFLnZS83Efzg83YuQcoKU17BC/FE5ypSEZn9YjXHR cpHsvZqWkYnTIbX8BrY7cCrHaAD+QvecF7VJOPtF6CcJpjWt79ztmGwYc5xWU9J98bbt bs7A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l3si7601737edv.214.2020.04.15.14.06.55; Wed, 15 Apr 2020 14:07:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2438870AbgDNK7l (ORCPT + 99 others); Tue, 14 Apr 2020 06:59:41 -0400 Received: from foss.arm.com ([217.140.110.172]:53102 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2438846AbgDNK7j (ORCPT ); Tue, 14 Apr 2020 06:59:39 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 71FBB1FB; Tue, 14 Apr 2020 03:59:38 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.30.4]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 413B03F6C4; Tue, 14 Apr 2020 03:59:36 -0700 (PDT) Date: Tue, 14 Apr 2020 11:59:23 +0100 From: Mark Rutland To: Xie XiuQi Cc: catalin.marinas@arm.com, will@kernel.org, tglx@linutronix.de, james.morse@arm.com, tanxiaofei@huawei.com, wangxiongfeng2@huawei.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: panic on synchronous external abort in kernel context Message-ID: <20200414105923.GA2486@C02TD0UTHF1T.local> References: <20200410015245.23230-1-xiexiuqi@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200410015245.23230-1-xiexiuqi@huawei.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 10, 2020 at 09:52:45AM +0800, Xie XiuQi wrote: > We should panic even panic_on_oops is not set, when we can't recover > from synchronous external abort in kernel context. > > Othervise, there are two issues: > 1) fallback to do_exit() in exception context, cause this core hung up. > do_sea() > -> arm64_notify_die > -> die > -> do_exit > 2) errors may propagated. > > Signed-off-by: Xie XiuQi > Cc: Xiaofei Tan > --- > arch/arm64/include/asm/esr.h | 12 ++++++++++++ > arch/arm64/kernel/traps.c | 2 ++ > 2 files changed, 14 insertions(+) > > diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h > index cb29253ae86b..acfc71c6d148 100644 > --- a/arch/arm64/include/asm/esr.h > +++ b/arch/arm64/include/asm/esr.h > @@ -326,6 +326,18 @@ static inline bool esr_is_data_abort(u32 esr) > return ec == ESR_ELx_EC_DABT_LOW || ec == ESR_ELx_EC_DABT_CUR; > } > > +static inline bool esr_is_inst_abort(u32 esr) > +{ > + const u32 ec = ESR_ELx_EC(esr); > + > + return ec == ESR_ELx_EC_IABT_LOW || ec == ESR_ELx_EC_IABT_CUR; > +} > + > +static inline bool esr_is_ext_abort(u32 esr) > +{ > + return esr_is_data_abort(esr) || esr_is_inst_abort(esr); > +} A data abort or an intstruction abort are not necessarily synchronus external aborts, so this isn't right. What exactly are you trying to catch here? If you are seeing a problem in practice, can you please share your log from a crash? Thanks, Mark. > + > const char *esr_get_class_string(u32 esr); > #endif /* __ASSEMBLY */ > > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c > index cf402be5c573..08f7f7688d5b 100644 > --- a/arch/arm64/kernel/traps.c > +++ b/arch/arm64/kernel/traps.c > @@ -202,6 +202,8 @@ void die(const char *str, struct pt_regs *regs, int err) > panic("Fatal exception in interrupt"); > if (panic_on_oops) > panic("Fatal exception"); > + if (esr_is_ext_abort(err)) > + panic("Synchronous external abort in kernel context"); > > raw_spin_unlock_irqrestore(&die_lock, flags); > > -- > 2.20.1 >