ARM: mm: Add workaround for erratum 763126
PATCH 1/1 ARM: mm: Add workaround for erratum 763126
From: "Arjun.K.V" <[email protected]>
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.
Workaround is to set the "Snoop-delayed exclusive handling" bit in the Auxiliary Control Register, ACTLR[31] to 1. This hardware is installed in each processor to detect that the load/store exclusive livelock scenario may be occurring and delay snoops for a period of time to allow the load exclusive/store exclusive loop to complete and make forward progress.
--- arch/arm/Kconfig | 13 +++++++++++++ arch/arm/mm/proc-v7.S | 43 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+)
arch/arm/Kconfig +13 -0
@@ -1464,6 +1464,19 @@ source "drivers/pci/pcie/Kconfig" source "drivers/pcmcia/Kconfig" +config ARM_ERRATA_763126 + bool "ARM errata: Three processor exclusive access livelock" + depends on CPU_V7 && SMP + help + This enables the workaround got ARM Erratum 763126. + 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. + Workaround is to set the "Snoop-delayed exclusive handling" bit + in the Auxiliary Control Register, ACTLR[31] to 1. + endmenu menu "Kernel Features"
arch/arm/mm/proc-v7.S +43 -0
55 lines not on this page · raw message
Signature · 1 line
1.7.9.5
PATCH 1/1 ARM: mm: Add workaround for erratum 763126
Arjun,
Thanks for sending this.
Quoted 58 lines · Arjun.K.V
From: "Arjun.K.V" <[email protected]>
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.Workaround is to set the "Snoop-delayed exclusive handling" bit in the Auxiliary Control Register, ACTLR[31] to 1. This hardware is installed in each processor to detect that the load/store exclusive livelock scenario may be occurring and delay snoops for a period of time to allow the load exclusive/store exclusive loop to complete and make forward progress.
Change-Id Idcf066e25ea6571a0f5da6f3a770318c1a9d6fffSigned-off-by Arjun.K.V <[email protected]>--- arch/arm/Kconfig | 13 +++++++++++++ arch/arm/mm/proc-v7.S | 43 +++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 56 insertions(+)arch/arm/Kconfig +13
-0@@ -1464,6 +1464,19 @@ source "drivers/pci/pcie/Kconfig" source "drivers/pcmcia/Kconfig" +config ARM_ERRATA_763126 + bool "ARM errata: Three processor exclusive access livelock" + depends on CPU_V7 && SMP + help + This enables the workaround got ARM Erratum 763126. + 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. + Workaround is to set the "Snoop-delayed exclusive handling" bit + in the Auxiliary Control Register, ACTLR[31] to 1. + endmenu menu "Kernel Features"arch/arm/mm/proc-v7.S +1
-0@@ -136,6 +136,29 @@ ENTRY(cpu_v7_do_resume) mcr p15, 0, r7, c2, c0, 1 @ TTB 1 #endif mcr p15, 0, r11, c2, c0, 2 @ TTB control register +
arch/arm/mm/proc-v7.S ENTRY(cpu_v7_do_resume) · line 149
Quoted 10 lines
arch/arm/mm/proc-v7.S +10
-0+#ifdef CONFIG_ARM_ERRATA_763126 + mrc p15, 0, r0, c0, c0, 0 @ Check if we are A15s + ubfx r1, r0, #4, #12 + ldr r2, =0x00000c0f + teq r1, r2 + bne 6f + and r1, r0, #0x00f00000 + and r2, r0, #0x0000000f + orr r2, r2, r1, lsr #20-4 + cmp r2, #0x20 @ Is the revision < r2p0
As I mentioned locally, I think this affects all A15s equally. Specifically, I see that:
* this affects r0p4
* this affects r2p0, r2p1, r2p2, r2p3, r2p4
* this affects r3p0, r3p1, r3p2, r3p3
* this affects r4p0
Just get rid of the revision test and assume that on all A15s (w/ 3 or more processors) you need this.
-Doug
PATCH 1/1 ARM: mm: Add workaround for erratum 763126
Hi guys,
Quoted 10 lines · Doug Anderson
Quoted 9 lines · Arjun.K.V
From: "Arjun.K.V" <[email protected]>
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?
Cheers,
Will
PATCH 1/1 ARM: mm: Add workaround for erratum 763126
Will,
Quoted 14 lines · Will Deacon
Hi guys,
Quoted 10 lines · Doug Anderson
Quoted 9 lines · Arjun.K.V
From: "Arjun.K.V" <[email protected]>
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.
Quoted 5 lines
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! :)
-Doug
PATCH 1/1 ARM: mm: Add workaround for erratum 763126
Quoted 19 lines · Doug Anderson
Quoted 12 lines · Will Deacon
Quoted 10 lines · Doug Anderson
Quoted 9 lines · Arjun.K.V
From: "Arjun.K.V" <[email protected]>
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.Quoted 5 lines
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?
Quoted 6 lines
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
A message that is not in the archive (sent off-list or not yet received): CAFY15YHPSLMh6iA1PQHjsneL_Kxarc0xL5uJ7_px71cbmJbrgQ@mail.gmail.com
PATCH 1/1 ARM: mm: Add workaround for erratum 763126
Quoted 5 lines · arjun kv
As Doug already mentioned, we have not observed an issue which could have been triggered by this erratum.
Nor do we have a method to actually trigger the livelock.
But if it improves the performance and has no real side effects, we could?at least?land this in our local tree?
It's up to you, but do some benchmarks first.
ACTLR bits that improve performance on specific SoCs should really be set by the firmware before booting the kernel. There is no way for the kernel to know what works best for your system, especially when we deal with implementation-defined registers.
Signature · 1 line
Catalin
PATCH 1/1 ARM: mm: Add workaround for erratum 763126
In reply to a message not in the archiveArjun,
Quoted 8 lines · arjun kv
Hi All,
As Doug already mentioned, we have not observed an issue which could have been triggered by this erratum.
Nor do we have a method to actually trigger the livelock.
But if it improves the performance and has no real side effects, we could at least land this in our local tree?
Right, this is not a discussion for upstream anymore. If Will and Catalin believe that this errata will not actually hit and that the worst case is a performance problem then not applying it makes sense.
We can continue the discussion in
<https://chromium-review.googlesource.com/#/c/169732/>, but given what I see here I'd even vote that we don't need to apply this locally.
Thanks to all for the review!
-Doug