Messages in this thread | | | Date | Tue, 7 Sep 1999 17:57:40 +0200 | From | Henner Eisen <> | Subject | passing skb ownership (was: ip_queue_xmit(): dangling skb pointer...) |
| |
David S Miller <davem@redhat.com> writes:
>> BTW: Is there any reason why the setting of the new skb's ownership is not >> done within skb_realloc_headroom() itself?
>Every time we've added an implicit side effect to a generic SKB >routines, it has lead to problems and hard to track down bugs. And it >is probably someone will find a situation where they _do not_ want to >set the new skb's ownership.
o.k.
Now, I realized that some network device drivers allocate new skb's, transfer the data from the old to the new skb and free the old skb.
E.g., ppp compression in drivers/{net/ppp.c,isdn/isdn_ppp.c} compress the contents of the original skb into a new allocated skb and then free the original skb. They do not pass the owner of the old skb to the new skb. I think they should. Otherwise, more skbuffs might be created and queued, eating up the kernel's memory without triggering the socket's flow control.
Is this right?
Maybe this does explain the performance problems occasionally observed with ppp and isdn_ppp links. (Maybe it even allows for a denial-of-service exploit by sending large amounts of data through a udp socket to a destination which is routed through a compressed ppp link. Well, the net_device's tbusy will probably protect protect against this.)
Henner
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |