Skip to contentSkip to conversation

Skb over panic on TUN device (2.6.18)

DISCUSSION Max Krasnyansky 1 participant 1 message Oct 4, 2007

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

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