Hi Greg,

Thanks for clarifying this bug, you did a much better job than I did. Sorry
I didn't describe it clearly.

I will created another patch, as you suggested.


William, below is the crash dump you requested.

[  645.832991] general protection fault: 0000 [#1] SMP PTI
[  645.833033] Modules linked in: veth vport_vxlan(OE) vport_stt(OE)
vport_lisp(OE) vport_geneve(OE) openvswitch(OE) tunnel6 nf_conntrack_ipv6
nf_defrag_ipv6 nf_nat_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
nf_nat nf_conntrack udp_tunnel netconsole rpcsec_gss_krb5 auth_rpcgss nfsv4
nfs vmw_vsock_vmci_transport vsock lockd grace fscache vmw_balloon sb_edac
joydev input_leds serio_raw coretemp vmw_vmci shpchp i2c_piix4 mac_hid
ib_iser rdma_cm iw_cm ib_cm ib_core sunrpc configfs iscsi_tcp libiscsi_tcp
libiscsi scsi_transport_iscsi autofs4 btrfs zstd_decompress zstd_compress
xxhash raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor
async_tx xor raid6_pq libcrc32c raid1 raid0 multipath linear hid_generic
usbhid hid crct10dif_pclmul crc32_pclmul ghash_clmulni_intel vmwgfx pcbc
ttm drm_kms_helper
[  645.836096]  syscopyarea sysfillrect sysimgblt fb_sys_fops drm psmouse
aesni_intel aes_x86_64 crypto_simd glue_helper cryptd mptspi mptscsih
mptbase vmxnet3 ahci libahci scsi_transport_spi pata_acpi
[  645.837697] CPU: 0 PID: 17724 Comm: handler2 Tainted: G           OE
 4.15.18 #1
[  645.838250] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 09/21/2015
[  645.839419] RIP: 0010:ip6erspan_tunnel_xmit+0x1da/0x6f0 [openvswitch]
[  645.839996] RSP: 0018:ffffb36d008177c0 EFLAGS: 00010286
[  645.840562] RAX: 00000000ffffffea RBX: ffff9be571e84000 RCX:
0000000000000040
[  645.841126] RDX: 000000000000003e RSI: ffff000071cf7e00 RDI:
ffff9be571cf7600
[  645.841697] RBP: ffffb36d00817880 R08: 0000000000000018 R09:
0000000000000000
[  645.842268] R10: ffffb36d00817a90 R11: 00000000fffffffe R12:
ffff9be5610e4400
[  645.842838] R13: 0000000000000000 R14: 0000000000000001 R15:
0000000000000000
[  645.843422] FS:  00007eff6e146700(0000) GS:ffff9be5bfc00000(0000)
knlGS:0000000000000000
[  645.844015] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  645.844607] CR2: 00007febc8f859d0 CR3: 000000005de8a002 CR4:
00000000001606f0
[  645.845250] Call Trace:
[  645.846070]  do_execute_actions+0x1505/0x1900 [openvswitch]
[  645.846686]  ? reserve_sfa_size+0x28/0x100 [openvswitch]
[  645.847319]  ? __ovs_nla_copy_actions+0x15c/0x6d0 [openvswitch]
[  645.847958]  ? __kmalloc_reserve.isra.39+0x2e/0x80
[  645.848581]  ? _cond_resched+0x16/0x40
[  645.849196]  ? __kmalloc+0x16d/0x1f0
[  645.849791]  ? ovs_execute_actions+0x48/0x120 [openvswitch]
[  645.850401]  ovs_execute_actions+0x48/0x120 [openvswitch]
[  645.851012]  ovs_packet_cmd_execute+0x267/0x2b0 [openvswitch]
[  645.851624]  genl_family_rcv_msg+0x1e9/0x380
[  645.852231]  genl_rcv_msg+0x47/0x90
[  645.852820]  ? genl_family_rcv_msg+0x380/0x380
[  645.853399]  netlink_rcv_skb+0xde/0x110
[  645.853962]  genl_rcv+0x24/0x40
[  645.854505]  netlink_unicast+0x183/0x240
[  645.855040]  netlink_sendmsg+0x2c2/0x3b0
[  645.855568]  sock_sendmsg+0x36/0x40
[  645.856074]  ___sys_sendmsg+0x2bc/0x2d0
[  645.856571]  ? ep_item_poll.isra.10+0x3b/0xc0
[  645.857045]  ? ep_send_events_proc+0x87/0x1a0
[  645.857501]  ? ep_read_events_proc+0xd0/0xd0
[  645.857940]  ? ep_scan_ready_list+0x1f3/0x200
[  645.858371]  ? ep_poll+0x1fb/0x3b0
[  645.858788]  ? __sys_sendmsg+0x51/0x90
[  645.859189]  __sys_sendmsg+0x51/0x90
[  645.859585]  do_syscall_64+0x6e/0x120
[  645.859964]  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[  645.860472] RIP: 0033:0x7eff6ec36a6d
[  645.860843] RSP: 002b:00007eff6e0e81a0 EFLAGS: 00000293 ORIG_RAX:
000000000000002e
[  645.861226] RAX: ffffffffffffffda RBX: 0000000000000002 RCX:
00007eff6ec36a6d
[  645.861622] RDX: 0000000000000000 RSI: 00007eff6e0e8200 RDI:
0000000000000011
[  645.862009] RBP: 00007eff6e0e8fe0 R08: 0000000000000000 R09:
00007eff6e0e9a60
[  645.862396] R10: 0000000000a5d340 R11: 0000000000000293 R12:
00000000009f7690
[  645.862775] R13: 00007eff6e0e8200 R14: 0000000000000002 R15:
00007eff6e0e86a0
[  645.863189] Code: 0f 85 a6 fe ff ff 45 31 c9 b8 ea ff ff ff 66 45 89 4c
24 3c 66 81 a3 1a 09 00 00 ff fb 49 8b 74 24 38 48 85 f6 0f 84 a2 fe ff ff
<0f> b6 96 f1 00 00 00 b8 ea ff ff ff f6 c2 01 0f 84 8d fe ff ff
[  645.864513] RIP: ip6erspan_tunnel_xmit+0x1da/0x6f0 [openvswitch] RSP:
ffffb36d008177c0
[  645.865043] ---[ end trace 25bab82318677b6f ]---
[  645.865452] Kernel panic - not syncing: Fatal exception in interrupt
[  645.865923] Kernel Offset: 0x3d000000 from 0xffffffff81000000
(relocation range: 0xffffffff80000000-0xffffffffbfffffff)
[  645.866752] ---[ end Kernel panic - not syncing: Fatal exception in
interrupt


On Thu, Aug 9, 2018 at 3:59 PM, Gregory Rose <[email protected]> wrote:

> On 8/8/2018 11:32 AM, Yifeng Sun wrote:
>
>> In compatable gre module, skb->cb is used as ovs_gso_cb.
>> This bug clears the 16-23 bit in the address of ovs_gso_cb.tun_dst.
>>
>> Signed-off-by: Yifeng Sun <[email protected]>
>> ---
>>   datapath/linux/compat/ip6_gre.c | 1 -
>>   1 file changed, 1 deletion(-)
>>
>> diff --git a/datapath/linux/compat/ip6_gre.c
>> b/datapath/linux/compat/ip6_gre.c
>> index 54a76ab..16c1f72 100644
>> --- a/datapath/linux/compat/ip6_gre.c
>> +++ b/datapath/linux/compat/ip6_gre.c
>> @@ -1146,7 +1146,6 @@ static netdev_tx_t ip6erspan_tunnel_xmit(struct
>> sk_buff *skb,
>>                 goto tx_err;
>>         t->parms.o_flags &= ~TUNNEL_KEY;
>> -       IPCB(skb)->flags = 0;
>>         tun_info = ovs_skb_tunnel_info(skb);
>>         if (unlikely(!tun_info ||
>>
>
> Yifeng,
>
> First, I'm sorry but you actually did identify the problem correctly at
> first, I just didn't see it.  My bad.
>
> Second, I'm no longer worried about removing the code.  It shouldn't be
> used in the case where
> we are not using USE_UPSTREAM_TUNNEL.  If USE_UPSTREAM_TUNNEL is defined
> then this entire
> module does not compile anyway.  So I think removing the IPCB macro that
> sets the flags to zero is fine.
>
> The same needs to be done in _gre6_xmit().
>
> Go ahead and resubmit the patch with the _gre6_xmit() case handled as well
> and I think that should be fine.
>
> Thanks for all your work!!!
>
> - Greg
>
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to