From: Mark Rutland <mark.rutland@arm.com> To: Xie XiuQi <xiexiuqi@huawei.com> 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 Date: Tue, 14 Apr 2020 11:59:23 +0100 [thread overview] Message-ID: <20200414105923.GA2486@C02TD0UTHF1T.local> (raw) In-Reply-To: <20200410015245.23230-1-xiexiuqi@huawei.com> 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 <xiexiuqi@huawei.com> > Cc: Xiaofei Tan <tanxiaofei@huawei.com> > --- > 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 >
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com> To: Xie XiuQi <xiexiuqi@huawei.com> Cc: catalin.marinas@arm.com, linux-kernel@vger.kernel.org, tanxiaofei@huawei.com, james.morse@arm.com, tglx@linutronix.de, will@kernel.org, wangxiongfeng2@huawei.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] arm64: panic on synchronous external abort in kernel context Date: Tue, 14 Apr 2020 11:59:23 +0100 [thread overview] Message-ID: <20200414105923.GA2486@C02TD0UTHF1T.local> (raw) In-Reply-To: <20200410015245.23230-1-xiexiuqi@huawei.com> 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 <xiexiuqi@huawei.com> > Cc: Xiaofei Tan <tanxiaofei@huawei.com> > --- > 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 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-04-14 10:59 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-04-10 1:52 [PATCH] arm64: panic on synchronous external abort in kernel context Xie XiuQi 2020-04-10 1:52 ` Xie XiuQi 2020-04-14 10:59 ` Mark Rutland [this message] 2020-04-14 10:59 ` Mark Rutland 2020-04-14 12:16 ` James Morse 2020-04-14 12:16 ` James Morse 2020-04-14 12:39 ` Xie XiuQi 2020-04-14 12:39 ` Xie XiuQi 2020-04-14 14:53 ` James Morse 2020-04-14 14:53 ` James Morse 2020-04-30 9:44 ` Xie XiuQi 2020-04-30 9:44 ` Xie XiuQi 2020-04-14 12:19 ` Xie XiuQi 2020-04-14 12:19 ` Xie XiuQi
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200414105923.GA2486@C02TD0UTHF1T.local \ --to=mark.rutland@arm.com \ --cc=catalin.marinas@arm.com \ --cc=james.morse@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=tanxiaofei@huawei.com \ --cc=tglx@linutronix.de \ --cc=wangxiongfeng2@huawei.com \ --cc=will@kernel.org \ --cc=xiexiuqi@huawei.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.