* Bug 75571 @ 2014-05-26 6:20 Alex 2014-06-01 14:43 ` Emil Goode 2014-06-02 21:19 ` Cong Wang 0 siblings, 2 replies; 12+ messages in thread From: Alex @ 2014-05-26 6:20 UTC (permalink / raw) To: netdev Hello! I caught a bug and adviced to post it to this list from https://bugzilla.kernel.org/show_bug.cgi?id=75571 I tried ifconfig interfaces down (both tun and ifb) before setting rules with no luck. This is new trace from kernel 3.2.59. [ 2945.851717] skb_under_panic: text:f9ca8566 len:209 put:148 head:ece89000 data:ece88fce tail:0xece8909f end:0xece89140 dev:tun4177 [ 2945.865020] ------------[ cut here ]------------ [ 2945.866000] kernel BUG at net/core/skbuff.c:119! [ 2945.866000] invalid opcode: 0000 [#1] SMP [ 2945.866000] Modules linked in: act_mirred sch_ingress sch_sfq cls_u32 sch_htb pl2303 usbserial pppoe pppox ppp_generic slhc ext4 jbd2 ipt_REJECT ipt_MASQUERADE xt_multiport xt_rateest xt_RATEEST xt_layer7 xt_HL xt_TPROXY nf_tproxy_core xt_set xt_connmark ipt_DF ipt_ULOG xt_socket ip6_tables nf_defrag_ipv6 xt_mark xt_conntrack xt_TCPMSS xt_tcpudp xt_DSCP xt_dscp iptable_raw iptable_mangle iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables x_tables ip_set_hash_net ip_set nfnetlink cpufreq_ondemand acpi_cpufreq freq_table processor mperf ipip coretemp hwmon nf_conntrack macvlan ifb tun ipmi_watchdog ipmi_si ipmi_msghandler pcspkr [ 2945.881815] [ 2945.881815] Pid: 0, comm: swapper/0 Not tainted 3.2.59 #1 Intel Corporation S3210SH/S3210SH [ 2945.881815] EIP: 0060:[<c05cbc64>] EFLAGS: 00010296 CPU: 0 [ 2945.881815] EIP is at skb_push+0x84/0x90 [ 2945.881815] EAX: 0000008b EBX: ece8909f ECX: 00000000 EDX: fffdd91d [ 2945.881815] ESI: f1960800 EDI: eb27c780 EBP: f540be24 ESP: f540bdf8 [ 2945.881815] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 [ 2945.881815] Process swapper/0 (pid: 0, ti=f540a000 task=c09cffa0 task.ti=c09c2000) [ 2945.881815] Stack: [ 2945.881815] c0988ec4 f9ca8566 000000d1 00000094 ece89000 ece88fce ece8909f ece89140 [ 2945.881815] f1960800 d7d77900 eb27ca80 f540be48 f9ca8566 00000000 c0a00e80 f2778800 [ 2945.881815] 00000001 f9ca8450 c9efcd60 eb27ca80 f540be60 c05f0f7f f540bf1c 00000000 [ 2945.881815] Call Trace: [ 2945.881815] [<f9ca8566>] ? tcf_mirred+0x116/0x15c [act_mirred] [ 2945.881815] [<f9ca8566>] tcf_mirred+0x116/0x15c [act_mirred] [ 2945.881815] [<f9ca8450>] ? tcf_mirred_dump+0x110/0x110 [act_mirred] [ 2945.881815] [<c05f0f7f>] tcf_action_exec+0x3f/0x80 [ 2945.881815] [<f9c860d2>] u32_classify+0x212/0x374 [cls_u32] [ 2945.881815] [<c043860d>] ? e1000_clean_rx_irq+0x27d/0x380 [ 2945.881815] [<c05edc01>] tc_classify_compat+0x31/0x70 [ 2945.881815] [<c05eeb44>] tc_classify+0x44/0xb0 [ 2945.881815] [<f9ca10f1>] ingress_enqueue+0x21/0x80 [sch_ingress] [ 2945.881815] [<c05d29c0>] __netif_receive_skb+0x2e0/0x4e0 [ 2945.881815] [<c05d2c8a>] process_backlog+0xca/0x1a0 [ 2945.881815] [<c05d4ba9>] net_rx_action+0xc9/0x1c0 [ 2945.881815] [<c013e95b>] __do_softirq+0x7b/0x110 [ 2945.881815] [<c013e8e0>] ? irq_enter+0x70/0x70 [ 2945.881815] [<c013e8e0>] ? irq_enter+0x70/0x70 [ 2945.881815] <IRQ> [ 2945.881815] [<c013e736>] ? irq_exit+0x66/0x90 [ 2945.881815] [<c0104786>] ? do_IRQ+0x46/0xb0 [ 2945.881815] [<c015801e>] ? sched_clock_idle_sleep_event+0xe/0x10 [ 2945.881815] [<c06d30a9>] ? common_interrupt+0x29/0x30 [ 2945.881815] [<c010a5a5>] ? mwait_idle+0x45/0x60 [ 2945.881815] [<c0102a5e>] ? cpu_idle+0x5e/0x90 [ 2945.881815] [<c068e138>] ? rest_init+0x58/0x60 [ 2945.881815] [<c0a037f1>] ? start_kernel+0x2f2/0x2f8 [ 2945.881815] [<c0a03329>] ? kernel_init+0x12f/0x12f [ 2945.881815] [<c0a030b3>] ? i386_start_kernel+0xb3/0xbb [ 2945.881815] Code: 5c 24 18 8b 88 a8 00 00 00 89 54 24 0c 89 4c 24 10 8b 40 50 c7 04 24 c4 8e 98 c0 89 44 24 08 8b 45 04 89 44 24 04 e8 e9 3b 10 00 <0f> 0b eb fe 90 8d b4 26 00 00 00 00 55 89 e5 56 53 83 ec 24 8b [ 2945.881815] EIP: [<c05cbc64>] skb_push+0x84/0x90 SS:ESP 0068:f540bdf8 [ 2946.207961] ---[ end trace e1338b3c42fd7015 ]--- [ 2946.213278] Kernel panic - not syncing: Fatal exception in interrupt [ 2946.220542] Pid: 0, comm: swapper/0 Tainted: G D 3.2.59 #1 [ 2946.228969] Call Trace: [ 2946.231856] [<c06cf73b>] panic+0x57/0x169 [ 2946.236592] [<c0105f25>] oops_end+0xc5/0xd0 [ 2946.241521] [<c0106025>] die+0x45/0x70 [ 2946.247879] [<c01039d3>] do_trap+0x83/0xa0 [ 2946.252715] [<c0103dd0>] ? do_coprocessor_segment_overrun+0x80/0x80 [ 2946.259978] [<c0103e56>] do_invalid_op+0x86/0xa0 [ 2946.265391] [<c05cbc64>] ? skb_push+0x84/0x90 [ 2946.270514] [<c0139f6f>] ? vprintk+0x18f/0x3e0 [ 2946.275736] [<c06d2922>] error_code+0x5a/0x60 [ 2946.280859] [<c0103dd0>] ? do_coprocessor_segment_overrun+0x80/0x80 [ 2946.288121] [<c05cbc64>] ? skb_push+0x84/0x90 [ 2946.293244] [<f9ca8566>] ? tcf_mirred+0x116/0x15c [act_mirred] [ 2946.300019] [<f9ca8566>] tcf_mirred+0x116/0x15c [act_mirred] [ 2946.306601] [<f9ca8450>] ? tcf_mirred_dump+0x110/0x110 [act_mirred] [ 2946.313865] [<c05f0f7f>] tcf_action_exec+0x3f/0x80 [ 2946.319466] [<f9c860d2>] u32_classify+0x212/0x374 [cls_u32] [ 2946.325958] [<c043860d>] ? e1000_clean_rx_irq+0x27d/0x380 [ 2946.332252] [<c05edc01>] tc_classify_compat+0x31/0x70 [ 2946.338154] [<c05eeb44>] tc_classify+0x44/0xb0 [ 2946.343374] [<f9ca10f1>] ingress_enqueue+0x21/0x80 [sch_ingress] [ 2946.350344] [<c05d29c0>] __netif_receive_skb+0x2e0/0x4e0 [ 2946.356540] [<c05d2c8a>] process_backlog+0xca/0x1a0 [ 2946.362248] [<c05d4ba9>] net_rx_action+0xc9/0x1c0 [ 2946.367762] [<c013e95b>] __do_softirq+0x7b/0x110 [ 2946.373177] [<c013e8e0>] ? irq_enter+0x70/0x70 [ 2946.378397] [<c013e8e0>] ? irq_enter+0x70/0x70 [ 2946.383617] <IRQ> [<c013e736>] ? irq_exit+0x66/0x90 [ 2946.389486] [<c0104786>] ? do_IRQ+0x46/0xb0 [ 2946.394414] [<c015801e>] ? sched_clock_idle_sleep_event+0xe/0x10 [ 2946.401386] [<c06d30a9>] ? common_interrupt+0x29/0x30 [ 2946.407287] [<c010a5a5>] ? mwait_idle+0x45/0x60 [ 2946.412604] [<c0102a5e>] ? cpu_idle+0x5e/0x90 [ 2946.417729] [<c068e138>] ? rest_init+0x58/0x60 [ 2946.422941] [<c0a037f1>] ? start_kernel+0x2f2/0x2f8 [ 2946.428647] [<c0a03329>] ? kernel_init+0x12f/0x12f [ 2946.434256] [<c0a030b3>] ? i386_start_kernel+0xb3/0xbb [ 2946.441242] Rebooting in 5 seconds.. [ 2946.441242] ACPI MEMORY or I/O RESET_REG. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug 75571 2014-05-26 6:20 Bug 75571 Alex @ 2014-06-01 14:43 ` Emil Goode 2014-06-02 10:32 ` Alex 2014-06-02 21:19 ` Cong Wang 1 sibling, 1 reply; 12+ messages in thread From: Emil Goode @ 2014-06-01 14:43 UTC (permalink / raw) To: Alex; +Cc: netdev Hello Alex, Perhaps you would like to try version 3.15-rc7 of the kernel and see if you can reproduce the bug? Best regards, Emil Goode On Mon, May 26, 2014 at 01:20:31PM +0700, Alex wrote: > Hello! > I caught a bug and adviced to post it to this list from > https://bugzilla.kernel.org/show_bug.cgi?id=75571 > > I tried ifconfig interfaces down (both tun and ifb) before setting rules > with no luck. This is new trace from kernel 3.2.59. > > [ 2945.851717] skb_under_panic: text:f9ca8566 len:209 put:148 > head:ece89000 data:ece88fce tail:0xece8909f end:0xece89140 dev:tun4177 > [ 2945.865020] ------------[ cut here ]------------ > [ 2945.866000] kernel BUG at net/core/skbuff.c:119! > [ 2945.866000] invalid opcode: 0000 [#1] SMP > [ 2945.866000] Modules linked in: act_mirred sch_ingress sch_sfq cls_u32 > sch_htb pl2303 usbserial pppoe pppox ppp_generic slhc ext4 jbd2 > ipt_REJECT ipt_MASQUERADE xt_multiport xt_rateest xt_RATEEST xt_layer7 > xt_HL xt_TPROXY nf_tproxy_core xt_set xt_connmark ipt_DF ipt_ULOG > xt_socket ip6_tables nf_defrag_ipv6 xt_mark xt_conntrack xt_TCPMSS > xt_tcpudp xt_DSCP xt_dscp iptable_raw iptable_mangle iptable_nat nf_nat > nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables x_tables > ip_set_hash_net ip_set nfnetlink cpufreq_ondemand acpi_cpufreq > freq_table processor mperf ipip coretemp hwmon nf_conntrack macvlan ifb > tun ipmi_watchdog ipmi_si ipmi_msghandler pcspkr > [ 2945.881815] > [ 2945.881815] Pid: 0, comm: swapper/0 Not tainted 3.2.59 #1 Intel > Corporation S3210SH/S3210SH > [ 2945.881815] EIP: 0060:[<c05cbc64>] EFLAGS: 00010296 CPU: 0 > [ 2945.881815] EIP is at skb_push+0x84/0x90 > [ 2945.881815] EAX: 0000008b EBX: ece8909f ECX: 00000000 EDX: fffdd91d > [ 2945.881815] ESI: f1960800 EDI: eb27c780 EBP: f540be24 ESP: f540bdf8 > [ 2945.881815] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 > [ 2945.881815] Process swapper/0 (pid: 0, ti=f540a000 task=c09cffa0 > task.ti=c09c2000) > [ 2945.881815] Stack: > [ 2945.881815] c0988ec4 f9ca8566 000000d1 00000094 ece89000 ece88fce > ece8909f ece89140 > [ 2945.881815] f1960800 d7d77900 eb27ca80 f540be48 f9ca8566 00000000 > c0a00e80 f2778800 > [ 2945.881815] 00000001 f9ca8450 c9efcd60 eb27ca80 f540be60 c05f0f7f > f540bf1c 00000000 > [ 2945.881815] Call Trace: > [ 2945.881815] [<f9ca8566>] ? tcf_mirred+0x116/0x15c [act_mirred] > [ 2945.881815] [<f9ca8566>] tcf_mirred+0x116/0x15c [act_mirred] > [ 2945.881815] [<f9ca8450>] ? tcf_mirred_dump+0x110/0x110 [act_mirred] > [ 2945.881815] [<c05f0f7f>] tcf_action_exec+0x3f/0x80 > [ 2945.881815] [<f9c860d2>] u32_classify+0x212/0x374 [cls_u32] > [ 2945.881815] [<c043860d>] ? e1000_clean_rx_irq+0x27d/0x380 > [ 2945.881815] [<c05edc01>] tc_classify_compat+0x31/0x70 > [ 2945.881815] [<c05eeb44>] tc_classify+0x44/0xb0 > [ 2945.881815] [<f9ca10f1>] ingress_enqueue+0x21/0x80 [sch_ingress] > [ 2945.881815] [<c05d29c0>] __netif_receive_skb+0x2e0/0x4e0 > [ 2945.881815] [<c05d2c8a>] process_backlog+0xca/0x1a0 > [ 2945.881815] [<c05d4ba9>] net_rx_action+0xc9/0x1c0 > [ 2945.881815] [<c013e95b>] __do_softirq+0x7b/0x110 > [ 2945.881815] [<c013e8e0>] ? irq_enter+0x70/0x70 > [ 2945.881815] [<c013e8e0>] ? irq_enter+0x70/0x70 > [ 2945.881815] <IRQ> > [ 2945.881815] [<c013e736>] ? irq_exit+0x66/0x90 > [ 2945.881815] [<c0104786>] ? do_IRQ+0x46/0xb0 > [ 2945.881815] [<c015801e>] ? sched_clock_idle_sleep_event+0xe/0x10 > [ 2945.881815] [<c06d30a9>] ? common_interrupt+0x29/0x30 > [ 2945.881815] [<c010a5a5>] ? mwait_idle+0x45/0x60 > [ 2945.881815] [<c0102a5e>] ? cpu_idle+0x5e/0x90 > [ 2945.881815] [<c068e138>] ? rest_init+0x58/0x60 > [ 2945.881815] [<c0a037f1>] ? start_kernel+0x2f2/0x2f8 > [ 2945.881815] [<c0a03329>] ? kernel_init+0x12f/0x12f > [ 2945.881815] [<c0a030b3>] ? i386_start_kernel+0xb3/0xbb > [ 2945.881815] Code: 5c 24 18 8b 88 a8 00 00 00 89 54 24 0c 89 4c 24 10 > 8b 40 50 c7 04 24 c4 8e 98 c0 89 44 24 08 8b 45 04 89 44 24 04 e8 e9 3b > 10 00 <0f> 0b eb fe 90 8d b4 26 00 00 00 00 55 89 e5 56 53 83 ec 24 8b > [ 2945.881815] EIP: [<c05cbc64>] skb_push+0x84/0x90 SS:ESP 0068:f540bdf8 > [ 2946.207961] ---[ end trace e1338b3c42fd7015 ]--- > [ 2946.213278] Kernel panic - not syncing: Fatal exception in interrupt > [ 2946.220542] Pid: 0, comm: swapper/0 Tainted: G D 3.2.59 #1 > [ 2946.228969] Call Trace: > [ 2946.231856] [<c06cf73b>] panic+0x57/0x169 > [ 2946.236592] [<c0105f25>] oops_end+0xc5/0xd0 > [ 2946.241521] [<c0106025>] die+0x45/0x70 > [ 2946.247879] [<c01039d3>] do_trap+0x83/0xa0 > [ 2946.252715] [<c0103dd0>] ? do_coprocessor_segment_overrun+0x80/0x80 > [ 2946.259978] [<c0103e56>] do_invalid_op+0x86/0xa0 > [ 2946.265391] [<c05cbc64>] ? skb_push+0x84/0x90 > [ 2946.270514] [<c0139f6f>] ? vprintk+0x18f/0x3e0 > [ 2946.275736] [<c06d2922>] error_code+0x5a/0x60 > [ 2946.280859] [<c0103dd0>] ? do_coprocessor_segment_overrun+0x80/0x80 > [ 2946.288121] [<c05cbc64>] ? skb_push+0x84/0x90 > [ 2946.293244] [<f9ca8566>] ? tcf_mirred+0x116/0x15c [act_mirred] > [ 2946.300019] [<f9ca8566>] tcf_mirred+0x116/0x15c [act_mirred] > [ 2946.306601] [<f9ca8450>] ? tcf_mirred_dump+0x110/0x110 [act_mirred] > [ 2946.313865] [<c05f0f7f>] tcf_action_exec+0x3f/0x80 > [ 2946.319466] [<f9c860d2>] u32_classify+0x212/0x374 [cls_u32] > [ 2946.325958] [<c043860d>] ? e1000_clean_rx_irq+0x27d/0x380 > [ 2946.332252] [<c05edc01>] tc_classify_compat+0x31/0x70 > [ 2946.338154] [<c05eeb44>] tc_classify+0x44/0xb0 > [ 2946.343374] [<f9ca10f1>] ingress_enqueue+0x21/0x80 [sch_ingress] > [ 2946.350344] [<c05d29c0>] __netif_receive_skb+0x2e0/0x4e0 > [ 2946.356540] [<c05d2c8a>] process_backlog+0xca/0x1a0 > [ 2946.362248] [<c05d4ba9>] net_rx_action+0xc9/0x1c0 > [ 2946.367762] [<c013e95b>] __do_softirq+0x7b/0x110 > [ 2946.373177] [<c013e8e0>] ? irq_enter+0x70/0x70 > [ 2946.378397] [<c013e8e0>] ? irq_enter+0x70/0x70 > [ 2946.383617] <IRQ> [<c013e736>] ? irq_exit+0x66/0x90 > [ 2946.389486] [<c0104786>] ? do_IRQ+0x46/0xb0 > [ 2946.394414] [<c015801e>] ? sched_clock_idle_sleep_event+0xe/0x10 > [ 2946.401386] [<c06d30a9>] ? common_interrupt+0x29/0x30 > [ 2946.407287] [<c010a5a5>] ? mwait_idle+0x45/0x60 > [ 2946.412604] [<c0102a5e>] ? cpu_idle+0x5e/0x90 > [ 2946.417729] [<c068e138>] ? rest_init+0x58/0x60 > [ 2946.422941] [<c0a037f1>] ? start_kernel+0x2f2/0x2f8 > [ 2946.428647] [<c0a03329>] ? kernel_init+0x12f/0x12f > [ 2946.434256] [<c0a030b3>] ? i386_start_kernel+0xb3/0xbb > [ 2946.441242] Rebooting in 5 seconds.. > [ 2946.441242] ACPI MEMORY or I/O RESET_REG. > > > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug 75571 2014-06-01 14:43 ` Emil Goode @ 2014-06-02 10:32 ` Alex 2014-06-02 17:38 ` Cong Wang 0 siblings, 1 reply; 12+ messages in thread From: Alex @ 2014-06-02 10:32 UTC (permalink / raw) To: netdev > Perhaps you would like to try version 3.15-rc7 of the kernel and > see if you can reproduce the bug? I cannot reproduce bug on 3.15-rc7. In changelog of 3.15-rc7 I see: "net_sched: fix an oops in tcindex filter." Is there any backport of this patch to 3.2 to check if it fixes problem? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug 75571 2014-06-02 10:32 ` Alex @ 2014-06-02 17:38 ` Cong Wang 0 siblings, 0 replies; 12+ messages in thread From: Cong Wang @ 2014-06-02 17:38 UTC (permalink / raw) To: Alex; +Cc: netdev On Mon, Jun 2, 2014 at 3:32 AM, Alex <d77190@mail.ru> wrote: >> Perhaps you would like to try version 3.15-rc7 of the kernel and >> see if you can reproduce the bug? > I cannot reproduce bug on 3.15-rc7. > > In changelog of 3.15-rc7 I see: "net_sched: fix an oops in tcindex > filter." > Is there any backport of this patch to 3.2 to check if it fixes problem? > It fixes a regression introduced in 3.14. It makes no sense to backport it to 3.2, nor it is relevant with the bug you reported. You should try a recent (stable) kernel to help us to debug the problem. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug 75571 2014-05-26 6:20 Bug 75571 Alex 2014-06-01 14:43 ` Emil Goode @ 2014-06-02 21:19 ` Cong Wang 2014-06-04 8:31 ` Alex 1 sibling, 1 reply; 12+ messages in thread From: Cong Wang @ 2014-06-02 21:19 UTC (permalink / raw) To: Alex; +Cc: netdev [-- Attachment #1: Type: text/plain, Size: 538 bytes --] On Sun, May 25, 2014 at 11:20 PM, Alex <d77190@mail.ru> wrote: > Hello! > I caught a bug and adviced to post it to this list from > https://bugzilla.kernel.org/show_bug.cgi?id=75571 > > I tried ifconfig interfaces down (both tun and ifb) before setting rules > with no luck. This is new trace from kernel 3.2.59. > > [ 2945.851717] skb_under_panic: text:f9ca8566 len:209 put:148 > head:ece89000 data:ece88fce tail:0xece8909f end:0xece89140 dev:tun4177 Could you try the following patch? We need to call skb_cow_head() before skb_push(). [-- Attachment #2: mirred.diff --] [-- Type: text/plain, Size: 542 bytes --] diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c index 4f912c0..35b8b8e 100644 --- a/net/sched/act_mirred.c +++ b/net/sched/act_mirred.c @@ -156,8 +156,14 @@ static int tcf_mirred(struct sk_buff *skb, const struct tc_action *a, goto out; if (!(at & AT_EGRESS)) { - if (m->tcfm_ok_push) + if (m->tcfm_ok_push) { + err = skb_cow_head(skb2, skb2->dev->hard_header_len); + if (err) { + kfree_skb(skb2); + goto out; + } skb_push(skb2, skb2->dev->hard_header_len); + } } /* mirror is always swallowed */ ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: Bug 75571 2014-06-02 21:19 ` Cong Wang @ 2014-06-04 8:31 ` Alex 2014-06-05 0:27 ` Cong Wang 0 siblings, 1 reply; 12+ messages in thread From: Alex @ 2014-06-04 8:31 UTC (permalink / raw) To: Cong Wang; +Cc: netdev > Could you try the following patch? We need to call skb_cow_head() before > skb_push(). This patch solves problem, no panic or any error messages. Thank you. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug 75571 2014-06-04 8:31 ` Alex @ 2014-06-05 0:27 ` Cong Wang 2014-06-05 5:22 ` Alex 0 siblings, 1 reply; 12+ messages in thread From: Cong Wang @ 2014-06-05 0:27 UTC (permalink / raw) To: Alex; +Cc: netdev On Wed, Jun 4, 2014 at 1:31 AM, Alex <d77190@mail.ru> wrote: >> Could you try the following patch? We need to call skb_cow_head() before >> skb_push(). > This patch solves problem, no panic or any error messages. > Thank you. > Thanks for testing! Thinking a bit more, the question is why skb_push(skb->dev->hard_header_len) is not correct here? It looks like we don't calculate tunnel->dev->hard_header_len correctly. But ipip_tunnel_bind_dev() should do the right thing less your setup is not correct, in that case your ipip tunnel should not receive any packet. We should be safe. Which is the interface routing to 192.168.18.17 on your system? Which driver does it use? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug 75571 2014-06-05 0:27 ` Cong Wang @ 2014-06-05 5:22 ` Alex 2014-06-05 19:18 ` Cong Wang 0 siblings, 1 reply; 12+ messages in thread From: Alex @ 2014-06-05 5:22 UTC (permalink / raw) To: Cong Wang; +Cc: netdev В Ср, 04/06/2014 в 17:27 -0700, Cong Wang пишет: > Thanks for testing! > > Thinking a bit more, the question is why > skb_push(skb->dev->hard_header_len) is not correct here? It looks > like we don't calculate tunnel->dev->hard_header_len correctly. But > ipip_tunnel_bind_dev() should do the right thing less your setup is not > correct, in that case your ipip tunnel should not receive any packet. > We should be safe. > > Which is the interface routing to 192.168.18.17 on your system? Which > driver does it use? Its a stock e1000e from kernel with no special options. No jumbo frames, etc. lspci says: Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06) IPIP tunnel runs on top of this interface. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug 75571 2014-06-05 5:22 ` Alex @ 2014-06-05 19:18 ` Cong Wang 2014-06-06 4:13 ` Alex 0 siblings, 1 reply; 12+ messages in thread From: Cong Wang @ 2014-06-05 19:18 UTC (permalink / raw) To: Alex; +Cc: netdev On Wed, Jun 4, 2014 at 10:22 PM, Alex <d77190@mail.ru> wrote: > В Ср, 04/06/2014 в 17:27 -0700, Cong Wang пишет: > >> Thanks for testing! >> >> Thinking a bit more, the question is why >> skb_push(skb->dev->hard_header_len) is not correct here? It looks >> like we don't calculate tunnel->dev->hard_header_len correctly. But >> ipip_tunnel_bind_dev() should do the right thing less your setup is not >> correct, in that case your ipip tunnel should not receive any packet. >> We should be safe. >> >> Which is the interface routing to 192.168.18.17 on your system? Which >> driver does it use? > > Its a stock e1000e from kernel with no special options. No jumbo frames, > etc. > > lspci says: > Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet > Controller (Copper) (rev 06) > > IPIP tunnel runs on top of this interface. > Hmm, e1000e should init dev->hard_header_len to ETH_LEN, which is 14. Plus IPv4 header len (20), it should be about 34. I don't understand why the ipip tunnel's hard_header_len is 148 in your case. It is only possible when there is no underlying interface, that is, LL_MAX_HEADER + sizeof(struct iphdr). What do `ip -d link show` and `ip route show` say? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug 75571 2014-06-05 19:18 ` Cong Wang @ 2014-06-06 4:13 ` Alex 2014-06-09 23:49 ` Cong Wang 0 siblings, 1 reply; 12+ messages in thread From: Alex @ 2014-06-06 4:13 UTC (permalink / raw) To: Cong Wang; +Cc: netdev > Hmm, e1000e should init dev->hard_header_len to ETH_LEN, which is 14. > Plus IPv4 header len (20), it should be about 34. I don't understand why > the ipip tunnel's hard_header_len is 148 in your case. It is only possible when > there is no underlying interface, that is, LL_MAX_HEADER + sizeof(struct iphdr). > > What do `ip -d link show` and `ip route show` say? 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:15:17:28:a7:02 brd ff:ff:ff:ff:ff:ff 7: eth0.99@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default link/ether 00:15:17:28:a7:02 brd ff:ff:ff:ff:ff:ff vlan protocol 802.1q id 99 <REORDER_HDR> 84: tun4177: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc htb state UNKNOWN mode DEFAULT group default link/ipip 192.168.18.199 peer 192.168.18.17 192.168.18.199 is loopback address. ip route show dev eth0.99 172.16.254.132/30 proto kernel scope link src 172.16.254.134 192.168.18.0/26 via 172.16.254.133 proto zebra .... and about 200 networks received via BGP ip route show dev tun4177 198.18.0.177 proto kernel scope link src 198.18.0.1 198.18.100.3 via 198.18.0.177 proto zebra metric 17 .... and about 500 routes to hosts recieved via OSPF ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Bug 75571 2014-06-06 4:13 ` Alex @ 2014-06-09 23:49 ` Cong Wang 2014-06-14 19:29 ` Alex 0 siblings, 1 reply; 12+ messages in thread From: Cong Wang @ 2014-06-09 23:49 UTC (permalink / raw) To: Alex; +Cc: netdev On Thu, Jun 5, 2014 at 9:13 PM, Alex <d77190@mail.ru> wrote: >> Hmm, e1000e should init dev->hard_header_len to ETH_LEN, which is 14. >> Plus IPv4 header len (20), it should be about 34. I don't understand why >> the ipip tunnel's hard_header_len is 148 in your case. It is only possible when >> there is no underlying interface, that is, LL_MAX_HEADER + sizeof(struct iphdr). >> >> What do `ip -d link show` and `ip route show` say? > > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > state UP mode DEFAULT group default qlen 1000 > link/ether 00:15:17:28:a7:02 brd ff:ff:ff:ff:ff:ff > > 7: eth0.99@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > noqueue state UP mode DEFAULT group default > link/ether 00:15:17:28:a7:02 brd ff:ff:ff:ff:ff:ff > vlan protocol 802.1q id 99 <REORDER_HDR> > > 84: tun4177: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc htb state > UNKNOWN mode DEFAULT group default > link/ipip 192.168.18.199 peer 192.168.18.17 > > > 192.168.18.199 is loopback address. > > ip route show dev eth0.99 > 172.16.254.132/30 proto kernel scope link src 172.16.254.134 > 192.168.18.0/26 via 172.16.254.133 proto zebra > .... and about 200 networks received via BGP > > ip route show dev tun4177 > 198.18.0.177 proto kernel scope link src 198.18.0.1 > 198.18.100.3 via 198.18.0.177 proto zebra metric 17 > .... and about 500 routes to hosts recieved via OSPF Hmm, looks correct so I still have no idea why dev->hard_header_len is not correct for your ipip tunnel, looks like the only possible reason is ip_route_output_ports() returns error for some reason. The best thing we can try is to fix it dynamically on rx, something like below (if you want to try this patch, please revert the previous one): diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c index 5dc5137..5eff109 100644 --- a/net/ipv4/ipip.c +++ b/net/ipv4/ipip.c @@ -407,6 +407,7 @@ static int ipip_rcv(struct sk_buff *skb) tstats->rx_packets++; tstats->rx_bytes += skb->len; + tunnel->dev->hard_header_len = skb->data - skb_mac_header(skb); __skb_tunnel_rx(skb, tunnel->dev); ipip_ecn_decapsulate(iph, skb); ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: Bug 75571 2014-06-09 23:49 ` Cong Wang @ 2014-06-14 19:29 ` Alex 0 siblings, 0 replies; 12+ messages in thread From: Alex @ 2014-06-14 19:29 UTC (permalink / raw) To: Cong Wang; +Cc: netdev > The best thing we can try is to fix it dynamically on rx, something > like below (if you want to try this patch, please revert the previous one): > > diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c > index 5dc5137..5eff109 100644 > --- a/net/ipv4/ipip.c > +++ b/net/ipv4/ipip.c > @@ -407,6 +407,7 @@ static int ipip_rcv(struct sk_buff *skb) > tstats->rx_packets++; > tstats->rx_bytes += skb->len; > > + tunnel->dev->hard_header_len = skb->data - skb_mac_header(skb); > __skb_tunnel_rx(skb, tunnel->dev); > > ipip_ecn_decapsulate(iph, skb); Thank you! This patch works too. But I think both patches are valid: act_mirred must not panic on receiving bad header len and ipip tunnel should not send incorrect header len too. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-06-14 19:29 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-05-26 6:20 Bug 75571 Alex 2014-06-01 14:43 ` Emil Goode 2014-06-02 10:32 ` Alex 2014-06-02 17:38 ` Cong Wang 2014-06-02 21:19 ` Cong Wang 2014-06-04 8:31 ` Alex 2014-06-05 0:27 ` Cong Wang 2014-06-05 5:22 ` Alex 2014-06-05 19:18 ` Cong Wang 2014-06-06 4:13 ` Alex 2014-06-09 23:49 ` Cong Wang 2014-06-14 19:29 ` Alex
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).