[ovs-dev] [PATCH] vxlan: fix kernel crash with vxlan gso

Yinpeijun yinpeijun at huawei.com
Tue Mar 31 02:57:05 UTC 2015


>> tcp flows with gso between two VMs in diffrent host, go through vxlan 
>> tunnel, cause kernel crash.
>>
>> Signed-off-by: caochengrong <caochengrong at huawei.com>
>> Signed-off-by: Arika Chen <arika.chen at huawei.com>
>
>What OVS and host kernel version is this for? I don't think this should be necessary, at least on master. vxlan_xmit_skb() calls udp_tunnel_handle_offloads(), 
>which calls ip_tunnel_handle_offloads(), which calls   skb_reset_inner_headers().

Thank you for your reply, The OVS version is the master and kernel version is 3.0.93-0.8-xen and the crash stack as follow:
[ 6006.808053]  [<ffffffff8034952c>] skb_segment+0x22c/0x670
[ 6006.808053]  [<ffffffff803962a8>] tcp_tso_segment+0x108/0x2a0
[ 6006.808053]  [<ffffffff803bb721>] inet_gso_segment+0xf1/0x270
[ 6006.808053]  [<ffffffff803533ca>] skb_gso_segment+0x13a/0x310
[ 6006.808053]  [<ffffffffa04f3ea9>] rpl_skb_gso_segment+0xb9/0xd0 [openvswitch]
[ 6006.808053]  [<ffffffffa04f34e3>] tnl_skb_gso_segment+0x1b3/0x2a0 [openvswitch]
[ 6006.808053]  [<ffffffffa04f36bb>] rpl_ip_local_out+0x9b/0xe0 [openvswitch]
[ 6006.808053]  [<ffffffffa04f3d82>] rpl_iptunnel_xmit+0x172/0x1e0 [openvswitch]
[ 6006.808053]  [<ffffffffa04ed65d>] vxlan_tnl_send+0x1ed/0x340 [openvswitch]
[ 6006.808053]  [<ffffffffa04ea07b>] ovs_vport_send+0xb/0x50 [openvswitch]
[ 6006.808053]  [<ffffffffa04db7ed>] do_execute_actions+0x3bd/0x620 [openvswitch]
[ 6006.808053]  [<ffffffffa04dba97>] ovs_execute_actions+0x47/0x130 [openvswitch]
[ 6006.808053]  [<ffffffffa04dcd53>] ovs_dp_process_packet+0xa3/0x170 [openvswitch]
[ 6006.808053]  [<ffffffffa04ea320>] ovs_vport_receive+0x80/0xa0 [openvswitch]
[ 6006.808053]  [<ffffffffa04ed43c>] netdev_frame_hook+0x2c/0x50 [openvswitch]
[ 6006.808053]  [<ffffffff803565ad>] __netif_receive_skb+0x2fd/0x7f0
[ 6006.808053]  [<ffffffff80356b67>] process_backlog+0xc7/0x220
[ 6006.808053]  [<ffffffff803579ee>] net_rx_action+0x13e/0x2a0
[ 6006.808053]  [<ffffffff8004db3f>] __do_softirq+0xff/0x240
[ 6006.808053]  [<ffffffff8041675c>] call_softirq+0x1c/0x30
[ 6006.808053]  [<ffffffff80008625>] do_softirq+0x95/0xd0
[ 6006.808053]  [<ffffffff80357f19>] netif_rx_ni+0x19/0x20
[ 6006.808053]  [<ffffffffa08f533e>] net_tx_action+0x90e/0x14a0 [netbk]
[ 6006.808053]  [<ffffffffa08f6bf9>] netbk_action_thread+0x89/0x1d0 [netbk]
[ 6006.808053]  [<ffffffff80069da6>] kthread+0x96/0xa0
[ 6006.808053]  [<ffffffff80416664>] kernel_thread_helper+0x4/0x10
[ 6006.808053] Code: 50 19 c0 49 89 70 58 41 c6 40 4c 04 83 e0 fc 83 c0 08 41 88 40 4d c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 
90 48 89 f8 89 d1 <f3> a4 c3 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 20 48 83 ea 20 4c 8b 
[ 6006.808053] RIP  [<ffffffff802242f5>] memcpy+0x5/0x120
[ 6006.808053]  RSP <ffff8801c5203750>

And after we add the patch, vm send tcp packets is ok. So what you think about ?




More information about the dev mailing list