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: Thu, 05 Apr 2007 19:51:24 +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 #44, bug #11400 (project lwip):

In my opinion, comment #34 had nothing to do with PBUF_RAM types. If we have
a queue of only RAM types, ref would be enough. But OK, when the user can
re-use a PBUF_RAM after giving it to udp_send(), then it must also be
copied.

re to #43:
> An external application shouldn't be using PBUF_RAM buffers to refer to its
own memory

Of course not to to refer to it's own memory. But I can imagine an app like
this:

- udp_recv callback is called
- app generates a unique packet into a PBUF_RAM
- calls udp_send() with that
- modifies the contents
- calls udp_send() again

So, is step 2 wrong? And wether step 4 & 5 are allowed or not, we have to
decide.

By the way, it's a different thing with tcp than udp: udp_send() gets a pbuf
while tcp_write() is given a buffer pointer. we _have_ the pbuf types because
we decided earlier if we copy or ref the data into a pbuf. A copy flag is not
needed! I still think that it is dangerous to modify any ref-counted object
that is referenced more than once!

But as a first start, I propose to take over the newest patch pasted here and
call pbuf_copy() on any pbuf except PBUF_ROM

    _______________________________________________________

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]