#132 ARM_CM4F: Missing CLREX in context switch

[Christopher Head]

The PendSV handler does not execute a CLREX instruction. That means that thread A could perform a LDREX, then thread B could perform a LDREX plus STREX (overwriting the target location) plus another LDREX, then thread A could perform a STREX which would erroneously succeed, violating atomicity. Doing a CLREX in the context switching code would result in the final STREX failing, as it should. This probably affects other ARM ports as well.

[Richard Barry]

Thanks you for taking the time to point this out.

A clrex instruction has been added after the line:

/* Save the new top of stack into the first member of the TCB. */
str r0, [r2]

in each affected port layer.

If you are happy with that then we can close this report.

[Richard Barry]

Change made, tested and checked in. Re-open this ticket if you think anything is in error.

[Christopher Head]

Yes, that sounds good. It doesn’t matter at all where the instruction is, as long as it runs sometime in the ISR. Thanks!

[Richard Barry]

Looking at this more closely I wonder if this is necessary at all. From
the ARM documentation:

"It is necessary to ensure that the local monitor is in the Open Access
state after a context switch. In ARMv7-M, the local monitor is changed
to Open Access automatically as part of an exception entry or exit
sequence."

As a context switch can only occur in an interrupt it would seem the
clrex is implicit in any case, so it is not necessary to explicitly call
the instruction.

This would seem to be shown experimentally.

[Christopher Head]

Wow, somehow I managed to completely miss that. I was looking at this page http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0008a/ch01s02s01.html, which says, “When an operating system performs a context switch, it must reset the local monitor to open state, to prevent false positives occurring. ARMv6K introduced the Clear-Exclusive instruction, CLREX, to reset the local monitor.”

I agree CLREX is not necessary for ARMv7-M targets, because the ExceptionTaken pseudocode procedure includes a ClearExclusiveLocal operation. Sorry for the false message!