Hi Martin,
On Fri, Mar 14, 2014 at 08:49:51AM +0000, Martin Townsend wrote:
> Hi Alex,
>
> Do we need to free local_skb if we fail?
>
> if (fail) {
> kfree_skb(local_skb);
> goto drop;
> }
>
you are right here. The current memory management is a mess. But I found
the reason why it's soo difficult to handle it. We run a kfree_skb on
fail in process_data. We don't should do this and handle the memory
management in lowpan_rcv function. I will fix this, thanks.
Otherwise we need to think more complex to check which function free's
the sk_buff... In this case on LOWPAN_DISPATCH_IPV6 we don't have a
lowpan_process call and also don't cleanup the sk_buff on error...
that's a currently a memory leak.
The fixup for this should be look like:
diff --git a/net/ieee802154/6lowpan_rtnl.c b/net/ieee802154/6lowpan_rtnl.c
index 2a146fb..240d857 100644
--- a/net/ieee802154/6lowpan_rtnl.c
+++ b/net/ieee802154/6lowpan_rtnl.c
@@ -189,7 +189,6 @@ static int process_data(struct sk_buff *skb)
lowpan_give_skb_to_devices);
drop:
- kfree_skb(skb);
return -EINVAL;
}
@@ -493,6 +492,7 @@ static int lowpan_rcv(struct sk_buff *skb, struct
net_device *dev,
drop_skb:
kfree_skb(skb);
drop:
+ kfree_skb(local_skb);
return NET_RX_DROP;
}
Tell me if you like this solution.
Another task on my todo list are the many skb_clone calls in this stack
to increase the sk_buff size... there exist a better way to handle this.
- Alex
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
