On Wed, Apr 05, 2006 at 11:39:05AM -0400, Vlad Yasevich wrote: > Hi All > > I am trying to understand if it is a good idea to have cloned skbs > reside on a frag_list? > > I've ran into a situation with SCTP, where it is possible to create > infinite recursion loops by having cloned skbs reside on a frag_list. > We end up in a situation where have two clones skb1 and skb2 that are > clones of the same original skb. Then we try adding skb2 to the > frag_list of skb1. Since both skb1 and skb2 share the skb_shared_info > structure, skb2's frag_list now points to skb2 creating a loop. > > This situation also appears to cause a memory leak where skb2 and the > actual data are not freed, because calling kfree_skb(skb1) should really > free the frag_list, but we can't do that because the skb on the frag > list holds the dataref on the same data. > > Can anyone say that putting clones on the frag_list is a BAD THING (tm) > and shouldn't be done? Or is there a way around it? > > Thanks you > -vlad > I would think that almost by definition having a cloned skb be on its own frag list would be a bad thing. IIRC fragmented ip packets allocate a sk_buff for the sole purpose of being the list leader in a fragmented packet.
Neil > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Lksctp-developers mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/lksctp-developers -- /*************************************************** *Neil Horman *Software Engineer *gpg keyid: 1024D / 0x92A74FA1 - http://pgp.mit.edu ***************************************************/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html