Mbed-os: pending ISR may execute after disabling interrupt

[odinthenerd]

If I am interpreting this correctly code resulting in the following (psydo) assembler would allow the load to happen before the pending ISR and thus causing many bugs in mbed.

str r0, ICER   #store mask into ICER (also known as NVIC_CLRENA on other chips)
ldr r1, r2       #load from SFR
<---- interrupt happens here because clear has not propagated yet
#use r1 although it is outdated due to modifications in the ISR

this would be one such example of a possible bug (after optimization of course)

edit: fixed link, should work now

[0xc0170]

If I am interpreting this correctly code resulting in the following (psydo) assembler would allow the load to happen before the pending ISR and thus causing many bugs in mbed.

the above link is broken?

cc @c1728p9 @bogdanm @geky

[odinthenerd]

thanks martin, link should work now.

[odinthenerd]

I wonder what ARM Internal Ref: IOTMORF-118 means, if you guys are serious about removing race conditions I would be glad to offer some pointers, I have stopped reporting most of them because no one seemed to be interested up 'till now. The USB stack for example is full of them, many which actually occur in typical user code on a regular basis.

[sg-]

@porkybrain Thanks

We'll start looking at these and if you want to help out, more than happy to collaborate!

[ciarmcom]

ARM Internal Ref: IOTMORF-511

[c1728p9]

Hi @porkybrain, thanks for reporting. I opened an issue to track this in CMSIS here: https://github.com/ARM-software/CMSIS_5/issues/110

[odinthenerd]

nice to see a definitive answer, after trying to actually reproduce the problem on hardware was not successful I was thinking it may just be an issue of me reading the spec in an overly paranoid way ;)