Re: SError Interrupt on CPU0, code 0xbf000000 makes kernel panic

From: Marc Zyngier <maz@kernel.org>
To: Joakim Tjernlund <Joakim.Tjernlund@infinera.com>
Cc: "robin.murphy@arm.com" <robin.murphy@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: SError Interrupt on CPU0, code 0xbf000000 makes kernel panic
Date: Thu, 24 Mar 2022 15:25:56 +0000	[thread overview]
Message-ID: <87mthf5q4b.wl-maz@kernel.org> (raw)
In-Reply-To: <f3bb3396ac913d86ada52007281024df37725dad.camel@infinera.com>

On Thu, 24 Mar 2022 15:11:42 +0000,
Joakim Tjernlund <Joakim.Tjernlund@infinera.com> wrote:
> 
> On Thu, 2022-03-24 at 15:05 +0000, Robin Murphy wrote:

> > Well, except when it is... try that on a Qualcomm SoC where the EL2
> > firmware will trap you and reset the system before you even know you've 
> > done anything wrong. If you know enough to know that an error triggered 
> > by accessing some address is truly benign, you know enough to avoid 
> > making that access in the first place.
> 
> of course the error will be dealt with but why make bug finding
> harder than it has to be?

Maybe that was not clear enough from our earlier replies. Let me try
again.

There is *nothing* more the kernel can do. We don't even know what
caused the access (read, write, earthquake or foreign power invasion).

By the time we get the SError interrupt, we could well be running
something altogether different because all of that is totally
asynchronous *by nature*. You're just lucky that you get the response
quickly enough that the kernel is still running the offending
userspace.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel