[Top] [All Lists]

Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (sm

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

> 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.


<Prev in Thread] Current Thread [Next in Thread>