[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20090227.161011.220557653.davem@davemloft.net>
Date: Fri, 27 Feb 2009 16:10:11 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: alexander.h.duyck@...el.com
Cc: herbert@...dor.apana.org.au, jeffrey.t.kirsher@...el.com,
emil.s.tantilov@...el.com, patrick.ohly@...el.com,
netdev@...r.kernel.org, gospo@...hat.com,
mitch.a.williams@...el.com
Subject: Re: [net-next PATCH] igb: remove skb_orphan calls
From: "Duyck, Alexander H" <alexander.h.duyck@...el.com>
Date: Fri, 27 Feb 2009 08:39:30 -0800
> The fact is, if you are planning to kill it further up the stack,
> you can put that down as another reason for removing the call. The
> timesync / killing skb->sk is a separate discussion that I don't
> know if I even really need to be involved in. The patch doesn't
> break anything, and removes a call to skb_orphan that shouldn't
> really be there in the first place.
That's not true at all.
One reason we haven't removed it yet is because there are some
semantic issues to address, which are also effected by drivers
doing this kind of by-hand skb_orphan()'ing.
For one thing, if you skb_orphan() in your transmit handler,
a UDP application can take over your network card by just
transmitting in an endless tight loop. It would be able to
nearly keep all other users from using the card.
That happens because if you skb_orphan(), nothing controls the
pace at which datagram applications can send. Currently
we need the socket send buffer limits to help us out here,
but if you skb_orphan() you completely subvert that proptection.
So I will not apply this patch.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists