lkml.org 
[lkml]   [1999]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectpassing 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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:3.274 / U:2.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site