lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [bug #11400] ARP multi-packet-queue modifies TCP unsent/una


From: Simon Goldschmidt
Subject: [lwip-devel] [bug #11400] ARP multi-packet-queue modifies TCP unsent/unacked segment packet pbuf chain into packet queue
Date: Wed, 04 Apr 2007 18:46:03 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

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

You're right about the returned pbuf. I think I was a little confused of the
names and because of the two chains, which made it complicated :-)

And I'm sorry I completely forgot about the PBUF_POOL/_RAM issue.
Using a PBUF_RAM, the whole function gets simpler, since the target pbuf is
not a chain.

>I thought that after all we would also need to copy RAM pbufs 

Hm, I don't know if we have to copy PBUF_RAM types (and IF yes, we would have
to copy everyting but PBUF_ROM). The contents of a pbuf may generally not be
changed after giving it to the stack as long as it is referenced more than
once (until the stack does not reference it any more). And as long as that's
true, we're safe. The problem with PBUF_REF is that it points to other data
that may be changed at any time after sending.

If the following should be OK for an application:

- create pbuf p
- copy data into it
- udp_send(p)
- change contents of p->payload

then we need to copy everything except PBUF_ROM. But my experience with
refcounting frameworks showed me you're not allowed to change an object you
give someone else to reference.
But as I don't know how lwip should handle this, I can't make the decision.

Finally, I'm attaching the patch with a new, smaller version of pbuf_copy().
I only try PBUF_RAM now. In my opinion, that's enough and we don't have to
revert to PBUF_POOL.

(file #12399)
    _______________________________________________________

Additional Item Attachment:

File name: arp_q3_pbuf.patch              Size:10 KB


    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Nachricht geschickt von/durch Savannah
  http://savannah.nongnu.org/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]