aboutsummaryrefslogtreecommitdiffstats
path: root/net/xfrm
diff options
context:
space:
mode:
authorEvgeniy Polyakov <johnpol@2ka.mipt.ru>2005-05-18 22:51:45 -0700
committerDavid S. Miller <davem@davemloft.net>2005-05-18 22:51:45 -0700
commitd48102007d068df7ba3055cdc1723e12db1ba30f (patch)
tree54f01cd1163bb552d5e1a647069663c4a28a1396 /net/xfrm
parentf7383c22246cfccbe912541dd83103009ed2b537 (diff)
downloadkernel_samsung_tuna-d48102007d068df7ba3055cdc1723e12db1ba30f.zip
kernel_samsung_tuna-d48102007d068df7ba3055cdc1723e12db1ba30f.tar.gz
kernel_samsung_tuna-d48102007d068df7ba3055cdc1723e12db1ba30f.tar.bz2
[XFRM]: skb_cow_data() does not set proper owner for new skbs.
It looks like skb_cow_data() does not set proper owner for newly created skb. If we have several fragments for skb and some of them are shared(?) or cloned (like in async IPsec) there might be a situation when we require recreating skb and thus using skb_copy() for it. Newly created skb has neither a destructor nor a socket assotiated with it, which must be copied from the old skb. As far as I can see, current code sets destructor and socket for the first one skb only and uses truesize of the first skb only to increment sk_wmem_alloc value. If above "analysis" is correct then attached patch fixes that. Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/xfrm')
-rw-r--r--net/xfrm/xfrm_algo.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
index 080aae2..2f4531f 100644
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -698,7 +698,7 @@ int skb_cow_data(struct sk_buff *skb, int tailbits, struct sk_buff **trailer)
return -ENOMEM;
if (skb1->sk)
- skb_set_owner_w(skb, skb1->sk);
+ skb_set_owner_w(skb2, skb1->sk);
/* Looking around. Are we still alive?
* OK, link new skb, drop old one */