stm32/rfcore: Fix race condition with C2 accessing free buffer list.

Prior to this commit, if C2 was busy (eg lots of BLE activity) then it may
not have had time to respond to the notification on the IPCC_CH_MM channel
by the time additional memory was available to put on that buffer.  In such
a case C1 would modify the free buffer list while C2 was potentially
accessing it, and this would eventually lead to lost memory buffers (or a
corrupt linked list).  If all buffers become lost then ACL packets
(asynchronous events) can no longer be delivered from C2 to C1.

This commit fixes this issue by waiting for C2 to indicate that it has
finished using the free buffer list.

Work done in collaboration with Jim Mussared aka @jimmo.

Signed-off-by: Damien George <damien@micropython.org>

1 files changed, 6 insertions, 0 deletions

diff --git a/ports/stm32/rfcore.c b/ports/stm32/rfcore.c
index 55fc229dd..878d5e1f8 100644
--- a/ports/stm32/rfcore.c
+++ b/ports/stm32/rfcore.c
@@ -417,6 +417,12 @@ STATIC void tl_process_msg(volatile tl_list_node_t *head, unsigned int ch, parse
 
         // If this node is allocated from the memmgr event pool, then place it into the free buffer.
         if ((uint8_t *)cur >= ipcc_membuf_memmgr_evt_pool && (uint8_t *)cur < ipcc_membuf_memmgr_evt_pool + sizeof(ipcc_membuf_memmgr_evt_pool)) {
+            // Wait for C2 to indicate that it has finished using the free buffer,
+            // so that we can link the newly-freed memory in to this buffer.
+            // If waiting is needed then it is typically between 5 and 20 microseconds.
+            while (LL_C1_IPCC_IsActiveFlag_CHx(IPCC, IPCC_CH_MM)) {
+            }
+
             // Place memory back in free pool.
             tl_list_append(&ipcc_mem_memmgr_free_buf_queue, cur);
             added_to_free_queue = true;