Re: [lwip-commits] [SCM] lwIP Contrib - Contributed code for Lightweight TCP/IP stack branch, master, updated. STABLE-2_0_0_RELEASE-191-g4c854d4

[Joel Cunningham]

On 1/2/2018 12:40 PM, address@hidden wrote:
> Joel Cunningham wrote:
> > [..]
> > which showed the problems in
> > bug #52719 and also some other problems with tcpip_init() and executing
> > the initfunc (which currently does not have the core lock held).
>
> We were already talking about the init phase earlier this day. The 
> problem here is that with our systems, the init phase is executed 
> before the OS is started (and all threads are of course created 
> suspended until the scheduler is started). In this setup, you can't 
> acquire the core lock (e.g. calling netif_add() after tcpip_init() 
> from your main function).
Ok, that makes sense and you're using the execution of the tcpip_thread 
to know when the "OS" has started for the purpose implementing 
sys_check_core_locking?

My RTOS environment is setup differently where LwIP is only inited after 
the OS is up and running.  Maybe adding some kind of "init_done" state 
variable could be used instead of looking at the tcpip_thread to know 
this information?

> If you're talking about the fact the the init callback is called from 
> tcpip_thread without the lock held, go ahead and fix it - you're right 
> ;-)
Yes this was the second issue I found after working around tcpip_init 
not having the core lock held during the call to lwip_init().  I agree 
this looks like a real bug and it didn't show up when running the win32 
test port due to checking 'current_thread_id == lwip_tcpip_thread_id'.  
I can push a fix

Joel