cpu/esp*: memory clobbers required for irq_* functions

[gschorcht]

Description

Based on discussions in PR #11440 it became clear that it might be also necessary for ESP architecture to add memory barriers to __asm__ volatile statements in irq_* functions.

[jcarrano]

Why? If for some code it is necessary to place a barrier, why not be explicit and place the barrier only where it is needed?

[kaspar030]

Why? If for some code it is necessary to place a barrier, why not be explicit and place the barrier only where it is needed?

The reason is that irq_*() is used to protect critical sections. The barriers are necessary to prevent the compiler from re-ordering memory orders load/stores over the critical section start/end.

Conceived example:

void list_add(list, new_node) {
  irq_disable();
  while (list->next) { list = list->next;}
  list->next = new_node;
  new_node = NULL;
  irq_restore();
}

Without a memory barrier in irq_restore(), the compiler is (theoretically) free to move the store in list->next = new_node after irq_restore().
If it does that, a parallel list_add(list, other_node) in an ISR or higher priority thread might get scheduled right after irq_restore(), write other_node at the the same position that then gets overwritten.

A lot of code in RIOT depends on this not happening, thus the need for barriers.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

[gschorcht]

This will be fixed with code deduplication in PR #12955 .

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.