From dd62c52a36e224cd0518d0361cc66a2f7e957f93 Mon Sep 17 00:00:00 2001 From: Damien George Date: Mon, 12 Apr 2021 16:21:54 +1000 Subject: [PATCH] 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 --- ports/stm32/rfcore.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/ports/stm32/rfcore.c b/ports/stm32/rfcore.c index 55fc229dd0..878d5e1f85 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;