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

[Albert Huitsing]

ah.. I see! thanks for your reaction !

I'm using FreeRTOS, and the SYS_ARCH_(UN)PROTECT() macros just enable/disable 
the global interrupts. I'll check if the sys_sem_signal() actually can cause a 
taskswitch (most probably it will). In that case I'll have to change the 
protect macros to explicitly stop task switching along with blocking irqs.

Albert

Op 25 dec. 2013 12:22 schreef "address@hidden" <address@hidden>:
>
> Albert Huitsing wrote: 
> > I've encountered a possible issue in src/api/sockets.c 
> > 
> > in the function event_callback() there seems to be a potential problem with 
> > detecting possible 
> > modification of the list while looping: 
> > 
> >        } 
> >        if (do_signal) { 
> >          scb->sem_signalled = 1; 
> >          /* Don't call SYS_ARCH_UNPROTECT() before signaling the semaphore, 
> >as this might 
> >             lead to the select thread taking itself off the list, 
> >invalidagin the semaphore. */ 
> >          sys_sem_signal(&scb->sem); 
> >        } 
> >      } 
> >      /* unlock interrupts with each step */ 
> >      last_select_cb_ctr = select_cb_ctr; 
> > 
> > 
> > the call to sys_sem_signal() could cause a modification of the list. 
> > 
> > so I think the 'select_cb_ctr' has to be stored *before* the call to 
> > sys_sem_signal() 
>
> The actual protection here is done through SYS_ARCH_PROTECT(), not by 
> the order of storing the pointer vs. semaphore signaling, so this should 
> be OK. 
>
> Simon 
>
> _______________________________________________ 
> lwip-devel mailing list 
> address@hidden 
> https://lists.nongnu.org/mailman/listinfo/lwip-devel