AR# 47586

Description

When a cacheable read receives an external abort, the aborted line is allocated as invalid in the Data Cache, and any allocation in the Data Cache clears the internal exclusive monitor. Therefore, if a program executes a LDREX/STREX loop, with the DSB instruction within, and it keeps on receiving an abort answer in the middle of the LDREX/STREX sequence, then the LDREX/STREX sequence never succeeds.

The issue happens in systems that might generate external aborts in answer to cacheable memory requests. There are two work-arounds: turn on the branch prediction or remove the DSB in the middle of the LDREX/STREX sequence.

Solution

On Cortex-A9, when a cacheable read receives an external abort, the aborted line is allocated as invalid in the Data Cache, and any allocation in the Data Cache clears the internal exclusive monitor. Therefore, if a program executes a LDREX/STREX loop which keeps on receiving an abort answer in the middle of the LDREX/STREX sequence, then the LDREX/STREX sequence never succeeds, leading to a possible processor livelock.

As an example, the following code sequence may exhibit the issue:

loop LDREX ... DSB STREX CMP BNE loop ...LDR (into aborting region)

The LDREX/STREX does not succeed on the first pass of the loop, and the BNE is predicted, so the LDR afterwards is speculatively executed and the processor keeps on executing:

LDR to aborting region (this speculative LDR now appears "before" the LDREX & DSB) LDREX DSB STREX 

The LDR misses in the L1 cache, and never gets allocated as valid because it is aborting.

The LDREX is executed, and sets the exclusive monitor.

The DSB is executed. It waits for the LDR to complete, which aborts, causing an allocation (as invalid) in the Data Cache, which clears the exclusive monitor The STREX is executed, but the exclusive monitor is now cleared, so the STREX fails.

The BNE may be predicted again, so the LDR is speculatively executed again, and the code loops back on the same failing LDREX/STREX sequence.

Impact Details

The issue happens in systems which may generate external aborts in answer to cacheable memory requests. If the program reaches a stable state where the internal exclusive monitor keeps on being cleared in the middle of the LDREX/STREX sequence, then the processor may encounter livelock.

In practice, this scenario seems very unlikely to happen because several conditions may prevent the erratum to happen:

• Usual LDREX/STREX code sequences do not contain any DSB, so that it is very unlikely that the system would return the abort answer precisely in the middle of the LDREX/STREX sequence on each iteration
• Some external irritators (e.g., interrupts) can happen and cause timing changes which can exit the processor from livelock.
• Branch prediction is very usually enabled, so the final branch in the loop will usually be correctly predicted after a few iterations of the loop, preventing the speculative LDR to be issued, so that the next iteration of the LDREX/STREX sequence will succeed.

Work-around Details

There are two work-arounds for this issue:

• Turn on the branch prediction.
• Remove the DSB in the middle of the LDREX/STREX sequence. If a DSB is truly required, it is strongly recommended to place it before the LDREX/STREX sequence, and implement the LDREX/STREX sequence as recommended by the ARM architecture.

Linked Answer Records

Master Answer Records