[Top] [All Lists]

[IPV4/IPV6] Ensure all frag_list members have NULL sk

To: Evgeniy Polyakov <johnpol@xxxxxxxxxxx>
Subject: [IPV4/IPV6] Ensure all frag_list members have NULL sk
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Sun, 15 May 2005 22:22:56 +1000
Cc: netdev@xxxxxxxxxxx, davem@xxxxxxxxxxxxx
In-reply-to: <20050515114121.GA4830@xxxxxxxxxxxxxxxxxxx>
References: <20050514134834.GA2698@xxxxxxxxxxxxxxxxxxxxxxxx> <E1DXE3h-0002jR-00@xxxxxxxxxxxxxxxxxxxxxxxx> <20050515104016.GA24344@xxxxxxxxxxxxxxxxxxx> <20050515114121.GA4830@xxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040907i
On Sun, May 15, 2005 at 09:41:21PM +1000, herbert wrote:
> I'll post a new patch soon.  However, since this is a pretty major change
> and the bugs it fixes aren't that important it should probably be delayed
> until 2.6.13.

Here it is:

Having frag_list members which holds wmem of an sk leads to nightmares
with partially cloned frag skb's.  The reason is that once you unleash
a skb with a frag_list that has individual sk ownerships into the stack
you can never undo those ownerships safely as they may have been cloned
by things like netfilter.  Since we have to undo them in order to make
skb_linearize happy this approach leads to a dead-end.

So let's go the other way and make this an invariant:

        For any skb on a frag_list, skb->sk must be NULL.

That is, the socket ownership always belongs to the head skb.
It turns out that the implementation is actually pretty simple.

The above invariant is actually violated in the following patch
for a short duration inside ip_fragment.  This is OK because the
offending frag_list member is either destroyed at the end of the
slow path without being sent anywhere, or it is detached from
the frag_list before being sent.

Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>

Visit Openswan at
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page:
PGP Key:

Attachment: p
Description: Text document

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