| To: | Imran.Patel@xxxxxxxxx |
|---|---|
| Subject: | Re: skb allocation problems |
| From: | Andi Kleen <ak@xxxxxxx> |
| Date: | Tue, 10 Apr 2001 08:07:13 +0200 |
| Cc: | netfilter-devel@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx |
| In-reply-to: | <2D6CADE9B0C6D411A27500508BB3CBD063CF07@eseis15nok>; from Imran.Patel@nokia.com on Mon, Apr 09, 2001 at 07:03:46PM +0300 |
| References: | <2D6CADE9B0C6D411A27500508BB3CBD063CF07@eseis15nok> |
| Sender: | owner-netdev@xxxxxxxxxxx |
| User-agent: | Mutt/1.2.5i |
On Mon, Apr 09, 2001 at 07:03:46PM +0300, Imran.Patel@xxxxxxxxx wrote:
> I have written a test module which closely mirrors what my code tries to
> do(attached below). This is what i get:
>
> PRE_R: old skb:c371ee40 new skb:c371ee30
I guess oldskb->len is <=0xc, and the slab allocator packs them near together
in the same zone.
> printk("\nPRE_R: old skb:%p", (*pskb)->data);
>
> /* translation happens in the real code here */
>
> skb = alloc_skb((*pskb)->len, GFP_ATOMIC);
> if(!skb)
> printk("alloc failed");
I guess you want a return here.
> skb_reserve(skb, 16);
You cannot do that if you didn't make sure that the old skb had enough
room for it (or rather it'll sometimes panic)
-Andi
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Kernel Panic for FTP with FreeBSD, Gregory Parrott |
|---|---|
| Next by Date: | RE: skb allocation problems, Imran . Patel |
| Previous by Thread: | skb allocation problems, Imran . Patel |
| Next by Thread: | Re: skb allocation problems, Rusty Russell |
| Indexes: | [Date] [Thread] [Top] [All Lists] |