[lwip-users] Reentrency problem within mem.c module
From:
EVS Hardware Dpt
Subject:
[lwip-users] Reentrency problem within mem.c module
Date:
Thu, 25 Oct 2007 16:55:16 +0200
Hello,
Recently we found a problem in our product. After some times we found that we had a reentrency problem within mem.c module.
In our application when sending data to our Ethernet driver, the driver call pbuf_ref(p) for each pbuf it receives then in the TX ISR handler, it calls pbuf_free(p). On the receive side, RX interrupt simply set a flag telling that some packets are waiting for service. I believe a lot of people here are using this kind of mechanism.
So beside the TX End ISR handler which only call pbuf_free as necessary, all other parts of the stack are running at normal level (ie not interrupt level). So there is effectively only one thread for the stack. We dont have an OS (NO_SYS = 1) but SYS_LIGHTWEIGHT_PROT = 1. Stack version is currently
1.1.1, but latest CVS version still exhibit this behavior.
Our problem :
We are receiving a lot of data (70MB/s rate on Gigabit interface), so the stack send a lot of ACK.
For each ACK, pbuf_alloc() is called, with pbuf flag as PBUF_RAM => mem_malloc is called, imagine at this point we have a TX Done interrupt, as no SYS_ARCH_PROTECT(lev) was called, the task is interrupted
TX Done Interrupt : we call pbuf_free(p) in our interrupt handler, which in turn call mem_free and cause our problem because we end up with inconsistencies with Heap management. Typically this fire an ASSERT in a subsequent
mem.c function.
In the source code, you can see that there was some protection in the form of sys_sem_wait/sys_sem_signal, but as previously mentioned, we don't use OS Primitives.
The solution of this problem, once found was simply to add SYS_ARCH_PROTECT protection mechanism as an alternative to sys_sem_xxx function already present. The generic form is :