Thanks David,
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index f8abf68..eb81f76 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -334,7 +334,7 @@ static void skb_release_data(struct sk_buff *skb)
> > if (!skb->cloned ||
> > !atomic_sub_return(skb->nohdr ? (1 << SKB_DATAREF_SHIFT) + 1 : 1,
> > &skb_shinfo(skb)->dataref)) {
> > - if (skb_shinfo(skb)->nr_frags) {
> > + if (skb_shinfo(skb)->nr_frags && skb_has_frags(skb)) {
> > int i;
> > for (i = 0; i < skb_shinfo(skb)->nr_frags; i++)
> > put_page(skb_shinfo(skb)->frags[i].page);
>
> skb_shinfo(skb)->nr_frags counts the number of entries contained
> in the skb_shinfo(skb)->frags[] array.
>
> This has nothing to do with the frag list pointer,
> skb_shinfo(skb)->frag_list, which is what skb_has_frags()
> tests.
>
> You've got some kind of memory corruption going on and it
> appears to have nothing to do with the code paths you're
> playing with here.
Do you have any recommendation on debugging technique/tool for this memory
corruption issue?
Best Regards
Abraham
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
