Re: [lwip-devel] [lwip-commits] [SCM] lwIP - A Lightweight TCPIP stack branch, master, updated. ea58a8103ceb70d20b88d37bfdbbe8ce8e9c6e71

[Sylvain Rochet]

Hello Simon,


On Mon, Mar 09, 2015 at 08:32:56AM +0100, Simon Goldschmidt wrote:
> Sylvain Rochet wrote:
> > PPP, PPPoS, fixed thread safety of pppos_input()
> > [..]
> > Added a mutex if PPP_INPROC_MULTITHREADED is set and ensure pppos_input()
> > is safe in regard to other pppos_* functions.
> 
> Hmm, the only problem I see here is that you now cannot call 
> pppos_input() from your serial RX interrupt any more...

Indeed, I didn't thought of that, thanks for the heads up :)


> I thought the purpose of PPP_INPROC_MULTITHREADED was that you did not 
> have to change context on each serial byte RX (whether from another 
> thread or from an interrupt)?

Yeah, obviously.


But I still want to fix the issue, even if nobody complained, that's the 
problem with threading issues which might only happens in very very very 
rare corner cases ;-)


What do you think about using pbuf_ref() in pppos_input() after 
pbuf_alloc() so pppos_free_current_input_packet() doesn't free the pbuf 
if it is still used by pppos_input() ?

There is still a problem, because pbuf_alloc() + pbuf_ref() must be 
called atomically in pppos_input() as well as if (pbuf_free(in) == 0) { 
in = NULL; } in pppos_free_current_input_packet(). What do you think 
about making those atomic using SYS_ARCH_PROTECT/SYS_ARCH_UNPROTECT ?


Sylvain

signature.asc
Description: Digital signature