lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT


From: Giuseppe Modugno
Subject: Re: [lwip-users] LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT
Date: Mon, 10 Oct 2022 18:32:15 +0200
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.2

I'm sorry to post again.

I just understood LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEX is used in mem.c for MEM_USE_POOLS=0 and MEM_LIBC_MALLOC=0 (default lwip heap management from a statically allocated buffer).

What about the reentrancy of memory pools? What happens when MEM_USE_POOLS=1 and pbuf_free is called in ISR, with or without LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT? It seems memory pools free is safe to be used from ISR, because I don't see any protection for them (differently of lwip default dynamic allocator).


Il 10/10/2022 18:22, Giuseppe Modugno ha scritto:
I'm sorry, I'm using MEM_USE_POOLS=0 *and* MEM_LIBC_MALLOC=1 *and* mem_clib_free/mem_clib_malloc redefined to a  custom buffer-based memory allocator (derived from mbedtls[1].


Il 10/10/2022 18:15, Giuseppe Modugno ha scritto:
After studying a little more, I understood the problem of using pbuf_free() in ISR can be solved in two ways:

 * by setting LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT to 1 (NO_SYS=0 or 1)
 * by using pub_free_callback() in ISR, instead of pbuf_free, only when
   NO_SYS=0

The first approach will add protection (disabling/enabling interrupts) when lwip needs malloc. This isn't a very good approach, because interrupts would be disabled frequently, but I haven't any knowledge with RTOS so it's much complex for me to add any to my project. So I'm working with the following configuration:

 * NO_SYS=1 (no OS)
 * LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEX=1 (because pbuf_free is called
   in ISR)
 * MEM_USE_POOLS=0 *and* mem_clib_free/mem_clib_malloc redefined to a
   custom buffer-based memory allocator (derived from mbedtls[1])

I suspect this scenario is not safe, because memory allocator from mbedtls isn't designed to be reentrant from an ISR (as for the memory pools of lwip when LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEX is set to 1). And for me is very difficult to fix the reentrancy problem of this allocator.

So I'm thinking the best solution to solve this problem without an OS is to abandon buffer-based memory allocator and migrate to another allocator that could be: lwip memory pools (MEM_USE_POOLS=1) or newlib heap (MEM_USE_POOLS=0 and mem_clib_malloc=malloc and mem_clib_free=free). What do you suggest?


Anyway I don't understand one thing. Why pbuf_free_callback() can't be called without an OS? It calls tcpip_try_callback that allocates a message for tcpip_thread. It shouldn't be difficult to create a list of pbufs that are waiting to be freed during sys_check_timeouts. What do you think?


[1] https://github.com/Mbed-TLS/mbedtls/blob/development/library/memory_buffer_alloc.c


Il 04/10/2022 16:46, Giuseppe Modugno ha scritto:
I started from an example of NXP SDK for LPC546xx MCUs. I'm using baremetal (NO_SYS=1) and I found the following warning in enet_ethernetif_lpc.c, function ethernetif_tx_release():

---
#if NO_SYS
#if defined(LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT) && LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT
        pbuf_free(p);
#else
#error "Bare metal requires LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT=1 because pbuf_free() is being called from an ISR"
#endif /* LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT */
...
---

It seems NXP code calls pbuf_free() inside ISR and this behaviour must be known to lwip by setting 1 to this macro. However it seems this macro is checked only in mem.c, if MEM_USE_POOLS is defined.

In my application I don't define MEM_USE_POOLS, so it is set to 0 by default in opt.h.

Does it mean I can avoid setting LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEX? I would like to set it to 0, because of the following warning found in opt.h:

---
 * ATTENTION: As you can see from the above description, this leads to dis-/  * enabling interrupts often, which can be slow! Also, on low memory, mem_malloc
 * can need longer.
---

However NXP code uses #error if this macro is not set, so I suspect there's a real risk to avoid setting it.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]