[<prev] [next>] [day] [month] [year] [list]
Message-ID: <4705540E.40903@qualcomm.com>
Date: Thu, 04 Oct 2007 13:58:54 -0700
From: Max Krasnyansky <maxk@...lcomm.com>
To: netdev@...r.kernel.org
Subject: Skb over panic on TUN device (2.6.18)
Folks,
I just got this panic report against 2.6.18 kernel and was wondering if some of you have
an idea of why this might happen.
The panic looks like this:
skb_over_panic: text:ffffffff880463db len:2840 put:1454 head:ffff81005df81000 data:ffff81005df81020
tail:ffff81005df81b38 end:ffff81005df81840 dev:tun0
skb_over_panic: text:ffffffff880463db len:1354 put:1314 head:ffff81007d77ee00 data:ffff81007d77ee20
tail:ffff81007d77f36a end:ffff81007d77ee80 dev:tun0
Those are two are unrelated and happened at different times.
It's coming from this piece of code:
if (!(skb = alloc_skb(len + align, GFP_KERNEL))) {
tun->stats.rx_dropped++;
return -ENOMEM;
}
if (align)
skb_reserve(skb, align);
if (memcpy_fromiovec(skb_put(skb, len), iv, len)) {
tun->stats.rx_dropped++;
kfree_skb(skb);
return -EFAULT;
}
As you can see there is not a whole lot that can go wrong with skb in there.
'align' is set to 0 for TUN devices.
First dumps looks as if skb already had no zero length right after allocation.
In the second dump skb is only 128 byte in size (end - head) even though
we're clearly allocating and trying to write more than that.
So, my conclusion at this point is that for whatever reason alloc_skb() returned
busted SKB. Probably because something in the slab got corrupted.
Any other thoughts ?
Thanx
Max
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists