[lwip-devel] [bug #44565] PPPOS support in tcpip thread breaks SLIP

[Sylvain Rochet]

Follow-up Comment #17, bug #44565 (project lwip):

> Although this is slightly off topic: isn't PPP_INPROC_MULTITHREADED 
> thread-safe when pppos_input() is called from an interrupt? The rest
> of the processing can then only be called from tcpip_thread, so
> pppos_input can interrupt PPP, but PPP cannot interrupt pppos_input.
> That's the way I designed it at least when appliying the fixes in the
> past. 

I am not sure, mainly because the pppos->in_state is not cleared by
pppos_input_free_current_packet().

[code]
void pppos_input(ppp_pcb *ppp, u8_t *s, int l) {

/* If we received a flag while we are in PDDATA */

} else if (cur_char == PPP_FLAG) {

/* and if by chance the FCS is valid */

        } else {
          struct pbuf *inp;
          /* Trim off the checksum. */
          if(pppos->in_tail->len > 2) {
            pppos->in_tail->len -= 2;

/* if pppos_input_free_current_packet() was called in the meanwhile (connect,
listen, or free) */

/* we are then dereferencing the in_tail buffer which is currently NULL */

[/code]


> I admit that "MULTITHREADED" is then not a very good name...

Indeed.


The main thing that tickle me is that I did the mistake of using
PPP_INPROC_MULTITHREADED in a non thread-safe way, even
with my overall perfect knowledge on how lwIP PPP stack is
working. That's mainly due to a total lack of documentation, but
even with that, if I did the mistake, then I am not the only one
going to.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?44565>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/