Re: [lwip-users] LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT

[Giuseppe Modugno]

Another thing I can't understand is why the code around LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT is needed if:

• NO_SYS=1
• MEM_USE_POOLS=0
• MEM_LIBC_MALLOC=0
• SYS_LIGHTWEIGHT_PROT=1
  
• sys_arch_protect() simply disables interrupts

In mem_malloc there's a point where LWIP_MEM_ALLOC_PROTECT is called, before the "scan through the heap searching for a free block". Why during the scan, for each loop, UNPROTECT/PROTECT are called? The comment says /* allow mem_free or mem_trim to run */.

Maybe this is done because the scan could take a long time to finish (for big and fragmented heap) and having interrupts disabled for so long time is not good? So the interrupts are enabled and disabled for each loop to give them opportunity to run?

Il 11/10/2022 11:10, Giuseppe Modugno ha scritto:

> Thanks
>       Simon. I want to summarize here all the possibilities with
>       NO_SYS=1, please confirm if I'm right.
>       
>       
>       ** MEM_USE_POOLS=0, MEM_LIBC_MALLOC=0
>       
>       lwip internal dynamic memory allocator from a static array
>       (implemented in mem.c)
>       
>       To use pbuf_free() in ISR (and main loop), we need to set
>       LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT *and* define
>       SYS_ARCH_PROTECT/UNPROTECT as macros that disable/enable
>       interrupts.
>       
>       Of course, sys_mutex_lock() and similar functions can be void,
>       because there's only one thread (mainloop) in NO_SYS=1.
>       
>       
>       ** MEM_USE_POOLS=1, MEM_LIBC_MALLOC=0
>       
>       Lwip memory pools used as dynamic memory allocator (mem.c and
>       memp.c)
>       
>       As you wrote, memory pools implementation in memp.c is reentrant,
>       so pub_free can be called safely from ISR, even without
>       LWIP_ALLOW_MEM_FREE_FROM_OTHER_CONTEXT.
>       
>       What I don't understand if SYS_ARCH_PROTECT (that is used in memp)
>       should disable interrupts or this isn't needed.
>       
>       If yes, this solution doesn't solve the problem of disabling
>       interrupts frequently.
>       
>       
>       ** MEM_USE_POOLS=1, MEM_LIBC_MALLOC=1
>       
>       Lwip malloc/free calls libc malloc/free
>       
>       In my case, I'm using newlib-nano. Even in this case, from newlib
>       documentation[1], I need to implement __malloc_lock/unlock that
>       must disable interrupts again.
>       
>       
>       
>       If all is correct, there isn't a "standard" solution to avoid
>       disabling interrupts when pbuf_free is called in ISR context
>       (always for NO_SYS=1).
>       
>       Anyway I think it shouldn't be so difficult to write a
>       pbuf_free_callback for NO_SYS=1 that pushes the pbuf to be freed
>       in a simple FIFO implementation.
>       
>       In the mainloop, a pbuf_free_task can be continuously called. This
>       function pops a pbuf from the FIFO and calls pbuf_free on it.
>       
>       
>       
>       [1]
>       https://sourceware.org/newlib/libc.html#g_t_005f_005fmalloc_005flock
>       
>       
>       
>       
>       Il 11/10/2022 06:25, Simon Goldschmidt ha scritto:
>       
> >         
> >         Am 10. Oktober 2022 18:32:15 MESZ schrieb Giuseppe Modugno
> >         <giuseppe.modugno.loqed@gmail.com>:
> >         
> > > 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).
> > >           
> > >         
> >         Yes, it is.
> >         
> >         
> >         Regards,
> >         
> >         Simon
> >         
> >         
> >         _______________________________________________
> >         
> >         lwip-users mailing list
> >         
> >         lwip-users@nongnu.org
> >         
> >         https://lists.nongnu.org/mailman/listinfo/lwip-users
> >         
> >       
>