[PATCH] arm64: errata: add workaround for cortex-a53 erratum #845719

[Will Deacon]

On Wed, Apr 22, 2015 at 08:37:27PM +0100, Kevin Hilman wrote:
> Hi Will,

Hi Kevin,

> On Tue, Mar 31, 2015 at 2:08 AM, Will Deacon <will.deacon at arm.com> wrote:
> > When running a compat (AArch32) userspace on Cortex-A53, a load at EL0
> > from a virtual address that matches the bottom 32 bits of the virtual
> > address used by a recent load at (AArch64) EL1 might return incorrect
> > data.
> >
> > This patch works around the issue by writing to the contextidr_el1
> > register on the exception return path when returning to a 32-bit task.
> > This workaround is patched in at runtime based on the MIDR value of the
> > processor.
> >
> > Reviewed-by: Marc Zyngier <marc.zyngier at arm.com>
> > Tested-by: Mark Rutland <mark.rutland at arm.com>
> > Signed-off-by: Will Deacon <will.deacon at arm.com>
> 
> Curious if you are planning to flag this for v3.19-stable?  I also
> noticed that the recent one from Bo Yan[1] for A57 might also be
> missing from stable/linux-3.19.y.  A quick check suggests they both
> apply cleanly to stable/linux-3.19.y

I wasn't planning on it, but if somebody wants it for 3.19 they could
certainly send it to Greg.

> Speaking of stable, is anyone at ARM working on getting these into
> older versions of stable?

No; although I was under the impression that Linaro had been tasked to do
the backports for LSK.

> For v3.18, I did a quick backport (and simple boot test on qemu) of
> Andre's framework plus the errata I'm aware of to stable/linux-3.18.y,
> and it seems to work (kernel reports "alternative: enabling workaround
> for ARM erratum 832075) so getting the framework plus errata into
> stable/linux-3.18.y seems like a good idea too and pretty straight
> forward too.

Backporting the entire alternatives framework to -stable sounds pretty
heavyweight to me, particularly if we have to go back as far as 3.10. We
could unconditionally backport the errata workarounds, but that would
require us to assess the performance impact on a variety of CPUs for each
of the backports, which I don't think is a good idea.

Will