# kernel panic when forwarding packets

## ktsaou

Hi all,

I run 3.5.7-gentoo on my system perfectly.

When I try to update to any version above that, when the linux starts forwarding packets, I get kernel panics like the one bellow.

I tried 3.10.17-gentoo, 3.11.6 vanilla and 3.12 vanilla.

The server can boot all these kernels and is perfectly usable without enabling packet forwarding.

The moment however, I enable the second interface and start routing packets, it panics.

Any ideas?

```
general protection fault: 0000 [#1] PREEMPT SMP

Modules linked in: nf_conntrack_netlink sch_htb ifb tun nfsd hwmon_vid coretemp bluetooth xt_REDIRECT ipt_MASQUERADE xt_owner iptable_nat nf_nat_ipv4 xt_length xt_TCPMSS xt_mark xt_connmark xt_DSCP xt_dscp iptable_mangle xt_helper ipt_REJECT ipt_ULOG xt_limit nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_nat_irc nf_conntrack_irc nf_nat_ftp nf_conntrack_ftp nf_nat_pptp nf_conntrack_pptp nf_nat_proto_gre nf_nat nf_conntrack_proto_gre iptable_filter ip_tables iTCO_wdt pegasus snd_usb_audio snd_usbmidi_lib snd_rawmidi pl2303 usbserial mii pcspkr lpc_ich i2c_i801 rtc_cmos mfd_core snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep xts glue_helper lrw gf128mul ablk_helper cryptd aes_x86_64 sha256_generic iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi tg3 ptp pps_core e1000 fuse btrfs libcrc32c zlib_deflate xhci_hcd pdc_adma sata_inic162x sata_mv sata_qstor sata_vsc sata_uli sata_sis sata_sx4 sata_nv sata_via sata_svw sata_sil24 sata_sil sata_promise pata_sl82c105 pata_cs5530 pata_cs5520 pata_via pata_marvell pata_sis pata_netcell pata_sc1200 pata_pdc202xx_old pata_triflex pata_atiixp pata_opti pata_amd pata_ali pata_it8213 pata_ns87415 pata_ns87410 pata_serverworks pata_cypress pata_oldpiix pata_artop pata_it821x pata_optidma pata_hpt3x2n pata_hpt3x3 pata_hpt37x pata_hpt366 pata_cmd64x pata_efar pata_rz1000 pata_sil680 pata_radisys pata_pdc2027x pata_mpiix

CPU: 0 PID: 9830 Comm: dhcpd Not tainted 3.11.6 #1

Hardware name: .   .  /IP35-E(Intel P35+ICH9R), BIOS 6.00 PG 05/30/2008

task: ffff880254689c80 ti: ffff88024e3bc000 task.ti: ffff88024e3bc000

RIP: 0010:[<ffffffff81101c90>]  [<ffffffff81101c90>] pagevec_move_tail+0x30/0x30

RSP: 0018:ffff88024e3bdb80  EFLAGS: 00010246

RAX: 0000000000000000 RBX: ffff88020a55e500 RCX: 00000000ffffffff

RDX: 0000000000000000 RSI: ffff88020a55e500 RDI: d288a05a809164c1

RBP: ffff88024e3bdba8 R08: 0000000000000046 R09: ffff88024e3bde58

R10: 0000000000000000 R11: 0000000000000000 R12: ffff880251b12c40

R13: 0000000000000001 R14: ffff88020a55e500 R15: 00000000000005dc

FS:  00007f4ece6fb700(0000) GS:ffff88025fc00000(0000) knlGS:0000000000000000

CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033

CR2: 00000000006b2fb4 CR3: 000000024e0ea000 CR4: 00000000000007f0

Stack:

 ffffffff81557bd5 ffff88024e3bdba8 ffff88020a55e500 ffff88020a55e500

 0000000000000000 ffff88024e3bdbc8 ffffffff81557c73 ffff88020a55e500

 ffff88020a55e500 ffff88024e3bdbe8 ffffffff81557cd1 ffff88024e3bded8

Call Trace:

 [<ffffffff81557bd5>] ? skb_release_data+0x75/0xf0

 [<ffffffff81557c73>] skb_release_all+0x23/0x30

 [<ffffffff81557cd1>] __kfree_skb+0x11/0xa0

 [<ffffffff81558187>] consume_skb+0x27/0xa0

 [<ffffffff8155e004>] skb_free_datagram+0x14/0x40

 [<ffffffff815d499a>] raw_recvmsg+0x15a/0x1c0

 [<ffffffff815e3145>] inet_recvmsg+0x95/0xc0

 [<ffffffff8154dd0f>] sock_recvmsg+0x7f/0xb0

 [<ffffffff8154dec4>] ? sockfd_lookup_light+0x24/0x90

 [<ffffffff8154ed9f>] SYSC_recvfrom+0xbf/0x120

 [<ffffffff8108d387>] ? ktime_get_ts+0x47/0xe0

 [<ffffffff81165ed8>] ? poll_select_copy_remaining+0xf8/0x140

 [<ffffffff81166ed4>] ? SyS_select+0x54/0x100

 [<ffffffff81551099>] SyS_recvfrom+0x9/0x10

 [<ffffffff8164d096>] system_call_fastpath+0x1a/0x1f

Code: 0c 10 81 48 89 e5 48 83 ec 10 48 8d 55 fc c7 45 fc 00 00 00 00 e8 d1 fe ff ff 48 63 45 fc 65 48 01 04 25 68 f0 00 00 c9 c3 66 90 <48> f7 07 00 c0 00 00 55 48 89 e5 75 1a f0 ff 4f 1c 0f 94 c0 84

RIP  [<ffffffff81101c90>] pagevec_move_tail+0x30/0x30

 RSP <ffff88024e3bdb80>

---[ end trace 45279617a0d2e03e ]---
```

----------

## olek

are you using hand-made configs for each major kernel version or did you recycle an old one using 

```
make oldconfig
```

?

could be that using an old config messed sth up.

----------

## ktsaou

 *olek wrote:*   

> are you using hand-made configs for each major kernel version or did you recycle an old one using 
> 
> ```
> make oldconfig
> ```
> ...

 

Yes I did oldconfig and also tried menuconfig, examining all options again.

----------

## ktsaou

Actually I use genkernel to compile and install everything.

I tried both --oldconfig and --menuconfig. Both give the same result.

----------

## olek

I never used genkernel so I have no idea whether it could screw up that much.

I would try to manually configure one, if that's an option. Good luck.

----------

## ktsaou

I tried vanilla 3.12.1.

Same results.

It starts with a panic like the one bellow (which is saved in /var/log/kern.log) and after 1-2 seconds it dumps two more (that are not saved in kern.log). I can only see very few lines of the later ones, although they do state several kernel functions about interrupts.

Is there any way to capture the later panics? I tried switching grub and boot code to the maximum console resolution supported, but still they do not fit in it.

 *Quote:*   

> Nov 23 12:09:22 box kernel: [   82.627772] BUG: unable to handle kernel NULL pointer dereference at           (null)
> 
> Nov 23 12:09:22 box kernel: [   82.628742] IP: [<ffffffff810f8310>] pagevec_move_tail+0x30/0x30
> 
> Nov 23 12:09:22 box kernel: [   82.628742] PGD 9b84a067 PUD 9b83e067 PMD 0 
> ...

 

----------

## jamapii

I use make oldconfig all the time, it does not cause kernel panics.

Broken hardware drivers cause kernel panics, I think this is happening here.

----------

