| To: | mostrows@xxxxxxxxxxxxx |
|---|---|
| Subject: | Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (smp, iptables?)) |
| From: | kuznet@xxxxxxxxxxxxx |
| Date: | Thu, 19 Jul 2001 22:17:52 +0400 (MSK DST) |
| Cc: | davem@xxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-net@xxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <sb666cohk89.fsf@xxxxxxxxxxxxxxxxxxx> from "Michal Ostrowski" at Jul 19, 1 02:00:54 pm |
| Sender: | owner-netdev@xxxxxxxxxxx |
Hello! > However, could we not have dev_queue_xmit behave as such (not free > frame on failure)? If you need to hold original skb, you may hold its refcnt. However, this feature inevitably results in big troubles: dev_queue_xmit() is allowed to change skb and you cannot assume anything about this. So that resuing skb dev_queue_xmit() is fatal bug not depending on anything. > The reason why I'm proposing this is that ppp_generic.c assumes that > the skb is still available after a transmission failure via pppoe. To > support the semantics of dev_queue_xmit and ppp_generic we would have > to always copy skb's inside pppoe_xmit. Then, if dev_queue_xmit fails > the original is deleted. You need not copy it. I said "clone". Nobody is allowed to touch _data_ part of skb, so that you need not to copy data. Alexey |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (smp, iptables?)), Michal Ostrowski |
|---|---|
| Next by Date: | Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (smp, iptables?)), Michal Ostrowski |
| Previous by Thread: | Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (smp, iptables?)), Michal Ostrowski |
| Next by Thread: | Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (smp, iptables?)), Michal Ostrowski |
| Indexes: | [Date] [Thread] [Top] [All Lists] |