Re: [lwip-users] Reentrency problem within mem.c module

[Simon Goldschmidt]

Hi,

I also encountered this problem when working with a DMA enabled MAC.  
As you said, this bug does still exist in CVS head, only nobody ever  
really cared to change it, I think.

The reason that _I_ didn't change it is CVS head includes a new  
option to forware mem_malloc() calls to new memp pools of different  
sizes (this was introduced to prevent memory fragmentation). And  
since memp_malloc() uses SYS_ARCH_PROTECT macros only, this solves  
your problem. The downside is that while memory fragmentation is  
prevented, memory usage is higher (because of the fixed size pools)  
_and_ you dont have it in v1.1.1!

The reason mem_malloc() doesn't use the SYS_ARCH_PROTECT macros is  
that this disables interrupt for  too long time span (if your heap is  
big and fragmented). And if your product has higher priority tasks  
than the TCPIP stack, these tasks might get slowed down.

A generic solution for this problem is to either let the user  
configure which protection to use or to put freed memory blocks on a  
list that i later processed in normal context. But to implement this,  
we would need a sys_sem_trywait() in the sys layer, which we  
currently haven't.

Anyway, could you please file a bug report on savannah so this bug  
doesn't get lost (if we don't fix it, it has to be documented).

Simon


Am 25.10.2007 um 16:55 schrieb EVS Hardware Dpt:

> 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 :
>
> #if SYS_LIGHTWEIGHT_PROT
>    SYS_ARCH_PROTECT(level)
> #else
>    sys_sem_wait(mem_sem)
> #endif /* SYS_LIGHTWEIGHT_PROT */
>
>
> I want to have your advice to known if it's something that must be  
> corrected (I believe so), or left as is.
>
> Thanks,
> Fred.
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users