[lwip-devel] [bug #11400] ARP multi-packet-queue modifies TCP unsent/unacked segment packet pbuf chain into packet queue

[Jonathan Larmour]

Follow-up Comment #24, bug #11400 (project lwip):

The reason I was saying about PBUF_REFs not coming from TCP was that it was
only TCP, not UDP which could _also_ have the packet on a different queue. So
I believe we should be able to just reuse and queue the pbufs directly after
all.

Also if we're copying, we should only need to copy the PBUF_REFs from the
chain, not the whole chain i.e. the whole packet. If nothing else this would
be good because the whole pbuf may be large, so is far less likely to permit
allocation with a single pbuf_alloc, which has to allocate one continuous
chunk.

Ideally I think PBUF_POOL should be kept for incoming packets only where
possible. Using a 1500 byte buffer for 60 byte data isn't so good.

Sorry I failed to see the existing etharp_q_entry stuff - I could have sworn
I updated my CVS.

About the memory leak (point 3 in comment 21) .... if the packet has been
passed to the ARP layer for it to later free, then it shouldn't be calling
pbuf_ref() on it at all. So I think you might be right that there's a problem
here, but the fix should be simple - remove the pbuf_ref in etharp_query. I
confess I'm not 100% certain and would have to think about it a bit more.

About Simon's point 4 in comment 21, you should never be in a position where
an individual pbuf in a queue gets deleted, as pbuf_queue() (currently) will
have pbuf_ref()d every packet (other than the head).



    _______________________________________________________

Reply to this item at:

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

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