Re: [lwip-devel] possible issue in sockets.c

[Albert Huitsing]

op 24-01-14 12:19, Simon Goldschmidt schreef:

Albert Huising wrote:

> you're saying that SYS_ARCH_PROTECT() should block all task switching alltogether? Is that really the intention of SYS_ARCH_PROTECT()?

 

Yes, it is. :-)

hmm...

as far as I understand things correctly then (note I'm on ARM / FreeRTOS)

1) SYS_ARCH_UNPROTECT() will call taskENTER_CRITICAL() and block IRQs -> blocking pre-emptive task switching. But this has no consequence for the SWI instruction on ARM:
2) sys_sem_signal() potentially calls portYIELD_WITHIN_API which is implemented by a 'SWI' instruction on ARM (see FreeRTOS's implementation of xSemaphoreGive / xQueueGenericSend)
3) the SWI instruction will NOT be blocked by blocking IRQs
--> so within sys_sem_signal() the task switch will NOT be blocked, which violates lwip's expected behaviour

Does nobody have this problem but me? Maybe somebody else could shine a light on it?

During a quick scan through the lwip code, I couldn't find the same situation again: every time SYS_ARCH_PROTECT() / SYS_ARCH_UNPROTECT() is called there is only plain vanilla code in-between (i.e.: no calls to RTOS functions) which strongs my belief that this *really* is a bug inside sockets.c only !

anyway the fix is simple enough: it's fixed when moving the last_select_cb_ctr = select_cb_ctr in front of the sys_sem_signal(). I'll stick to that for now :-)

kindest regards,

Albert Huitsing

-- 
Albert Huitsing (address@hidden)
Huitsing Embedded Systems
Dr. Mondenweg 5
7831 JA  Nw. Weerdinge
+31-(0)591-521222
http://www.huitsing.nl
"conformity is the uncomfortable feeling of wearing 
 somebody else's clothes; even when they don't fit"