On 06.12.2019 14:09, Ophir Munk wrote:
> Hi Ilya,
> I applied this series on master ("dpdk: Update to use DPDK 19.11.") and
> PINGed between two "dpdk" ports (hw-offload=true).
> It worked fine.
> Then I watched flow statistics (dpif based) by executing the command in (1):
> (1) watch ovs-appctl dpif/dump-flows -m <bridge name>
> It worked fine.
> Then I watched flow statistics (dpctl based) by executing the command in (2):
> (2) watch ovs-appctl dpctl/dump-flows
> In this case OVS crashed after a few seconds.
>
> When inspecting the calls trace I notice that pmd->dp->dpif->dpif_class->type
> is a corrupted memory address.
>
> (gdb) bt
> #0 0x0000000000c26fda in dpif_normalize_type (type=0x7372 <Address 0x7372
> out of bounds>) at lib/dpif.c:517
> #1 0x0000000000c19864 in dp_netdev_flow_offload_put
> (offload=offload@entry=0x7f11fc00b790) at lib/dpif-netdev.c:2378
> #2 0x0000000000c19ca8 in dp_netdev_flow_offload_main (data=<optimized out>)
> at lib/dpif-netdev.c:2467
> #3 0x0000000000ca3c9d in ovsthread_wrapper (aux_=<optimized out>) at
> lib/ovs-thread.c:383
> #4 0x00007f12a2a08e25 in start_thread () from /lib64/libpthread.so.0
> #5 0x00007f12a222c34d in clone () from /lib64/libc.so.6
>
> This scenario repeats whenever running the command in (2) and when the code
> calls dpif_normalize_type().
> It seems to me that the memory corruption was there for a while but only now
> it is exposed due to your rfc series.
>
> In order to observe this memory corruption I added the following printouts.
> I tested it with hw-offload=false:
> ovs-vsctl set Open_vSwitch . other_config:hw-offload=false
> I tested it on latest master without your rfc series.
>
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> index 1e54936..18a804a 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -3625,6 +3625,10 @@ dpif_netdev_flow_dump_next(struct
> dpif_flow_dump_thread *thread_,
> }
> }
>
> + VLOG_ERR("pmd->dp=%p pmd->dp->dpif=%p pmd->dp->dpif->dpif_class=%p \
> + pmd->dp->dpif->full_name=%s",
> + pmd->dp, pmd->dp->dpif, pmd->dp->dpif->dpif_class,
> + pmd->dp->dpif->full_name);
> do {
> for (n_flows = 0; n_flows < flow_limit; n_flows++) {
> struct cmap_node *node;
>
>
> Looking at the printouts the memory corruption is observed.
>
> Initially all printouts are identical and correct as expected.
>
> dpif_netdev(revalidator82)|ERR|pmd->dp=0x7fdfea3ea010 pmd->dp->dpif=0x2525e70
> pmd->dp->dpif->dpif_class=0xef3e80 pmd->dp->dpif->full_name=netdev@ovs-netdev
> dpif_netdev(revalidator82)|ERR|pmd->dp=0x7fdfea3ea010 pmd->dp->dpif=0x2525e70
> pmd->dp->dpif->dpif_class=0xef3e80 pmd->dp->dpif->full_name=netdev@ovs-netdev
> dpif_netdev(revalidator82)|ERR|pmd->dp=0x7fdfea3ea010 pmd->dp->dpif=0x2525e70
> pmd->dp->dpif->dpif_class=0xef3e80 pmd->dp->dpif->full_name=netdev@ovs-netdev
>
> Around this point I executed the dpctl command in (2) and you can notice that
> the pointers pmd->dp->dp_dpif and beyond became modified.
>
> dpif_netdev(revalidator82)|ERR|pmd->dp=0x7fdfea3ea010 pmd->dp->dpif=0x25c3280
> pmd->dp->dpif->dpif_class=0x251c790 pmd->dp->dpif->full_name=(null)
> dpif_netdev(revalidator82)|ERR|pmd->dp=0x7fdfea3ea010 pmd->dp->dpif=0x25c3280
> pmd->dp->dpif->dpif_class=0x33c03608 pmd->dp->dpif->full_name=
> dpif_netdev(revalidator82)|ERR|pmd->dp=0x7fdfea3ea010 pmd->dp->dpif=0x25c3280
> pmd->dp->dpif->dpif_class=0x2605700 pmd->dp->dpif->full_name=
> dpif_netdev(revalidator82)|ERR|pmd->dp=0x7fdfea3ea010 pmd->dp->dpif=0x25c3280
> pmd->dp->dpif->dpif_class=0xe784250b pmd->dp->dpif->full_name=memseg-2048k-0-3
> dpif_netdev|ERR|pmd->dp=0x7fdfea3ea010 pmd->dp->dpif=0x2602430
> pmd->dp->dpif->dpif_class=0xef3e80 pmd->dp->dpif->full_name=netdev@ovs-netdev
> dpif_netdev(revalidator82)|ERR|pmd->dp=0x7fdfea3ea010 pmd->dp->dpif=0x2602430
> pmd->dp->dpif->dpif_class=0x2606200 pmd->dp->dpif->full_name=(null)
>
> The same happens if I test it with hw-offload=true.
>
> I hope this scenario can be recreated on other setups as well.
This is interesting. I'll try to reproduce this issue on my setup.
> I will look more into it.
Thanks!
Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
