[PATCH] ARM: mm: Add workaround for erratum 763126

[will.deacon@arm.com (Will Deacon)]

On Thu, May 08, 2014 at 06:57:10PM +0100, Doug Anderson wrote:
> On Thu, May 8, 2014 at 10:38 AM, Will Deacon <will.deacon@arm.com> wrote:
> > On Thu, May 08, 2014 at 05:57:03PM +0100, Doug Anderson wrote:
> >> On Wed, May 7, 2014 at 10:55 PM, Arjun.K.V <arjun.kv@samsung.com> wrote:
> >> > From: "Arjun.K.V" <arjun.kv@samsung.com>
> >> >
> >> > Three processor exclusive access livelock.
> >> > In a system with three or more coherent masters that all use
> >> > the ldrex/strex synchronization primitives to access a semaphore
> >> > in coherent cacheable memory, there is a possibility of a
> >> > livelock condition where two masters continuously attempt
> >> > and fail to get the lock while the third master
> >> > continuously reads the lock.
> >
> > Tentative NAK. You're paraphrasing the bug to make it sound worse than it
> > is -- whilst two of the cores need to be in a ldrex/strex loop, the third
> > needs to be issuing snoops from a normal load (to get the line into a shared
> > state). Please can you point me at the code in Linux which is triggering
> > this issue?
> 
> Arjun can correct me if I'm wrong, but I don't think there is any
> known way to trigger the issue.  We haven't landed this fix locally in
> our tree because there has been no evidence showing that it increases
> stability.  If you guys say that it's a correct fix then we'll still
> land it, but if (as you say) it's impossible to trigger in Linux then
> it's a good reason to skip it!  :)

We basically don't think that any sane code would hit it. Now, there could
be insane code hanging out in userspace, so I'm prepared to believe that
this could lead to performance issues there but interrupts would fix the
lockup so it's not the end of the world.

Will