Re: [lwip-devel] Require sys_arch_protect/unprotect to be correctly nested?

[Joel Cunningham]

> On Jul 19, 2017, at 8:15 AM, Douglas <address@hidden> wrote:
> 
> Most uses of sys_arch_protect/unprotect appear to be nested correctly,
> so that it is unnecessary to note the current nesting level. It is not
> uncommon for a recursive mutex implementation to not expose the level
> and to require matching acquire and release operations. The FreeRTOS
> vPortEnterCritical function does not return a nesting level.
> 
> So would a change to require sys_arch_protect/unprotect to have matching
> nesting be considered, perhaps even cleaning these up by removing the
> *DECL_PROTECT macros and the levels?

The DECL_PROTECT and levels allow SYS_ARCH_PROTECT to be implemented as 
disable/enable interrupts for a uni-processor system.

> 
> A quick inspection suggests one non-nested use in alloc_socket, but that
> looks like a programming error and a patch will be submitted.
> 
> 
> There is a use of these in socket.c:event_callback that looks
> problematic. There is a code comment:
> 
> "Don't call SYS_ARCH_UNPROTECT() before signaling the semaphore, as this
> might lead to the select thread taking itself off the list, invalidating
> the semaphore."
> 
> If sys_arch_protect were implemented via a mutex then could the above
> really offer the required protection?
> 

Could you describe the problem here?  Also note that SYS_ARCH_PROTECT is only 
used in that section of event_callback if not using LWIP_TCPIP_CORE_LOCKING 
(which is enabled by default)

Joel