Herbert Xu
4906f9985e
bridge: Fix LRO crash with tun
> Kernel BUG at drivers/net/tun.c:444
> invalid opcode: 0000 [1] SMP
> last sysfs file: /class/net/lo/ifindex
> CPU 0
> Modules linked in: tun ipt_MASQUERADE iptable_nat ip_nat xt_state ip_conntrack
> nfnetlink ipt_REJECT xt_tcpudp iptable_filter d
> Pid: 6912, comm: qemu-kvm Tainted: G 2.6.18-128.el5 #1
> RIP: 0010:[<ffffffff886f57b0>] [<ffffffff886f57b0>]
> :tun:tun_chr_readv+0x2b1/0x3a6
> RSP: 0018:ffff8102202c5e48 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff8102202c5e98 RCX: 0000000004010000
> RDX: ffff810227063680 RSI: ffff8102202c5e9e RDI: ffff8102202c5e92
> RBP: 0000000000010ff6 R08: 0000000000000000 R09: 0000000000000001
> R10: ffff8102202c5e94 R11: 0000000000000202 R12: ffff8102275357c0
> R13: ffff81022755e500 R14: 0000000000000000 R15: ffff8102202c5ef8
> FS: 00002ae4398db980(0000) GS:ffffffff803ac000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00002ae4ab514000 CR3: 0000000221344000 CR4: 00000000000026e0
> Process qemu-kvm (pid: 6912, threadinfo ffff8102202c4000, task
> ffff81022e58d820)
> Stack: 00000000498735cb ffff810229d1a3c0 0000000000000000 ffff81022e58d820
> ffffffff8008a461 ffff81022755e528 ffff81022755e528 ffffffff8009f925
> 000005ea05ea0000 ffff8102209d0000 00001051143e1600 ffffffff8003c00e
> Call Trace:
> [<ffffffff8008a461>] default_wake_function+0x0/0xe
> [<ffffffff8009f925>] enqueue_hrtimer+0x55/0x70
> [<ffffffff8003c00e>] hrtimer_start+0xbc/0xce
> [<ffffffff886f58bf>] :tun:tun_chr_read+0x1a/0x1f
> [<ffffffff8000b3f3>] vfs_read+0xcb/0x171
> [<ffffffff800117d4>] sys_read+0x45/0x6e
> [<ffffffff8005d116>] system_call+0x7e/0x83
>
>
> Code: 0f 0b 68 40 62 6f 88 c2 bc 01 f6 42 0a 08 74 0c 80 4c 24 41
> RIP [<ffffffff886f57b0>] :tun:tun_chr_readv+0x2b1/0x3a6
> RSP <ffff8102202c5e48>
> <0>Kernel panic - not syncing: Fatal exception
This crashed when an LRO packet generated by bnx2x reached a
tun device through the bridge. We're supposed to drop it at
the bridge. However, because the check was placed in br_forward
instead of __br_forward, it's only effective if we are sending
the packet through a single port.
This patch fixes it by moving the check into __br_forward.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
2009-02-09 15:07:18 -08:00
..
2009-02-06 22:07:41 -08:00
2008-11-20 20:32:15 -08:00
2009-01-26 12:37:53 -08:00
2009-01-07 17:21:44 -08:00
2008-12-08 01:14:16 -08:00
2008-12-28 12:49:40 -08:00
2009-01-07 17:23:17 -08:00
2009-02-09 15:07:18 -08:00
2009-01-14 21:06:55 -08:00
2009-02-06 22:06:43 -08:00
2009-01-04 17:29:21 -08:00
2009-01-11 00:17:22 -08:00
2008-12-10 15:18:31 -08:00
2009-01-06 16:45:26 -08:00
2008-07-19 22:34:43 -07:00
2008-11-23 23:24:32 -08:00
2009-02-06 01:59:12 -08:00
2009-02-09 15:01:19 -08:00
2008-11-03 18:21:05 -08:00
2009-01-02 10:19:43 -08:00
2009-01-06 10:44:34 -08:00
2009-01-25 20:49:14 -08:00
2008-01-28 14:56:52 -08:00
2008-11-21 17:15:03 -08:00
2009-01-22 13:55:01 -05:00
2009-02-09 14:34:56 -08:00
2008-12-31 12:54:11 -05:00
2009-01-07 10:00:17 -08:00
2008-12-28 12:49:40 -08:00
2009-02-01 01:53:29 -08:00
2009-01-07 17:24:34 -08:00
2009-01-04 17:11:24 -08:00
2008-12-28 12:49:40 -08:00
2009-02-06 21:50:52 -08:00
2009-01-12 21:54:40 -08:00
2009-01-22 14:53:23 -08:00
2009-02-03 15:20:13 -08:00
2009-01-11 00:06:33 -08:00
2008-12-31 18:07:37 -05:00
2008-11-20 04:26:21 -08:00
2009-01-29 17:18:31 -08:00
2009-01-29 15:46:43 -05:00
2008-11-03 18:21:05 -08:00
2009-01-20 09:49:51 -08:00
2008-11-19 18:49:57 -08:00
2009-01-26 12:25:55 -08:00
2009-01-07 10:00:17 -08:00
2006-03-28 09:16:06 -08:00
2009-01-14 14:15:27 +01:00
2008-07-27 09:45:34 -07:00