"David S. Miller" wrote:
> The only difference is that you are explicitly setting
> SKB 'sk' ownership in your by-hand version, skb_copy_expand
> seems to be doing everything else you are doing, except that
> one thing. So maybe you could try:
>
> if (max_headroom > skb_headroom(skb)
> || max_tailroom > skb_tailroom(skb)) {
> struct sk_buff *n= skb_copy_expand(skb, max_headroom,
> max_tailroom, GFP_ATOMIC);
> if (!n) {
> printk(KERN_INFO "%s: Out of memory, dropped packet\n",
> dev->name);
> goto tx_error;
> }
> dev_kfree_skb(skb);
> if (skb->sk)
> skb_set_owner_w(n, skb->sk);
> skb = n;
> }
>
> I have a sneaking suspicion that will make it work for you.
>
> Later,
> David S. Miller
> davem@redhat.com
David, sorry for calling you Dave first off... I thought I saw you
called that before. It seems something else is the problem too. I
still get the exact same symptoms with that code enabled with your
changes.
Is it possible one of the n->whatever = someoddthing lines is magical
and needs to be there? I am going to dig into this skb_copy_expand
thing. Below are the few that I think might be the trick:
n->list=NULL;
n->sk=NULL;
n->h.raw=skb->h.raw+offset;
n->nh.raw=skb->nh.raw+offset;
n->mac.raw=skb->mac.raw+offset;
n->is_clone=0;
atomic_set(&n->users, 1);
n->destructor = NULL;
I definitely do not know enough to rule out any of the other lines, but
it seems they just do what a copy might do. The other option is still
is skb_copy_expand broken?
I do so appreciate your help David. I hope with your help and that of
others I can wrap this up and make the patch open to all knowing that it
works.
Sincerely, with much gratitude,
Trever Adams
-- For the finest in family and value oriented products: http://www.daysofyore.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:16 EST