RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1609643 - Running/destroying testpmd in guest which enabling vIOMMU can cause host ovs-vswitchd[10869]: segfault
Summary: Running/destroying testpmd in guest which enabling vIOMMU can cause host ovs-...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openvswitch
Version: 7.6
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Maxime Coquelin
QA Contact: Pei Zhang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-30 05:43 UTC by Pei Zhang
Modified: 2020-01-14 22:31 UTC (History)
13 users (show)

Fixed In Version: openvswitch-2.9.0-59.el7fdn
Doc Type: No Doc Update
Doc Text:
undefined
Clone Of:
Environment:
Last Closed: 2018-11-05 14:59:03 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Guest XML (5.24 KB, text/html)
2018-07-30 05:43 UTC, Pei Zhang
no flags Details

Description Pei Zhang 2018-07-30 05:43:20 UTC
Created attachment 1471414 [details]
Guest XML

Description of problem:

This is testing with enabling vIOMMU support.

Boot ovs, then boot VM. Start testpmd in guest, then kill it, start it again will cause ovs-vswitchd segfault. 


Version-Release number of selected component (if applicable):
openvswitch-2.9.0-55.el7fdp.x86_64
3.10.0-927.el7.x86_64
qemu-kvm-rhev-2.12.0-8.el7.x86_64
libvirt-4.5.0-4.el7.x86_64
tuned-2.9.0-1.el7.noarch
dpdk-17.11-10.el7fdb.x86_64


How reproducible:
100%


Steps to Reproduce:
1. Boot ovs, refer to[1]

2. Boot VM, full xml is attached.

3. Start testpmd in guest, refer to[3]

4. Destroy testpmd

# ps aux | grep testpmd
root      1653  370  0.8 4406036 70496 pts/0   SLl+ 13:33   3:34 /usr/bin/testpmd -l 1,2,3,4,5 -n 4 -d /usr/lib64/librte_pmd_virtio.so.1 -w 0000:06:00.0 -w 0000:07:00.0 -- --nb-cores=4 --disable-hw-vlan -i --disable-rss --rxq=2 --txq=2
...
# kill -9 1653


5. Start testpmd again, refer to[5], ovs segfault.

# dmesg (in host)
...
[11531.550929] ovs-vswitchd[11947]: segfault at 2ab07ffb1002 ip 0000557a3552d360 sp 00007f5a037fd4d0 error 4 in ovs-vswitchd[557a3533b000+4b8000]


Actual results:

Guest testpmd operations can cause host ovs crash.


Expected results:

ovs should not crash.


Reference:
[1]
# cat boot_ovs_client.sh 
#!/bin/bash

set -e

echo "killing old ovs process"
pkill -f ovs-vswitchd || true
sleep 5
pkill -f ovsdb-server || true

echo "probing ovs kernel module"
modprobe -r openvswitch || true
modprobe openvswitch

echo "clean env"
DB_FILE=/etc/openvswitch/conf.db
rm -rf /var/run/openvswitch
mkdir /var/run/openvswitch
rm -f $DB_FILE

echo "init ovs db and boot db server"
export DB_SOCK=/var/run/openvswitch/db.sock
ovsdb-tool create /etc/openvswitch/conf.db /usr/share/openvswitch/vswitch.ovsschema
ovsdb-server --remote=punix:$DB_SOCK --remote=db:Open_vSwitch,Open_vSwitch,manager_options --pidfile --detach --log-file
ovs-vsctl --no-wait init

echo "start ovs vswitch daemon"
ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true
ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-socket-mem="1024,1024"
ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-lcore-mask="0x1"
ovs-vsctl --no-wait set Open_vSwitch . other_config:vhost-iommu-support=true
ovs-vswitchd unix:$DB_SOCK --pidfile --detach --log-file=/var/log/openvswitch/ovs-vswitchd.log

echo "creating bridge and ports"

ovs-vsctl --if-exists del-br ovsbr0
ovs-vsctl add-br ovsbr0 -- set bridge ovsbr0 datapath_type=netdev
ovs-vsctl add-port ovsbr0 dpdk0 -- set Interface dpdk0 type=dpdk options:dpdk-devargs=0000:04:00.0 
ovs-vsctl add-port ovsbr0 vhost-user0 -- set Interface vhost-user0 type=dpdkvhostuserclient options:vhost-server-path=/tmp/vhostuser0.sock
ovs-ofctl del-flows ovsbr0
ovs-ofctl add-flow ovsbr0 "in_port=1,idle_timeout=0 actions=output:2"
ovs-ofctl add-flow ovsbr0 "in_port=2,idle_timeout=0 actions=output:1"

ovs-vsctl --if-exists del-br ovsbr1
ovs-vsctl add-br ovsbr1 -- set bridge ovsbr1 datapath_type=netdev
ovs-vsctl add-port ovsbr1 dpdk1 -- set Interface dpdk1 type=dpdk options:dpdk-devargs=0000:04:00.1
ovs-vsctl add-port ovsbr1 vhost-user1 -- set Interface vhost-user1 type=dpdkvhostuserclient options:vhost-server-path=/tmp/vhostuser1.sock
ovs-ofctl del-flows ovsbr1
ovs-ofctl add-flow ovsbr1 "in_port=1,idle_timeout=0 actions=output:2"
ovs-ofctl add-flow ovsbr1 "in_port=2,idle_timeout=0 actions=output:1"

ovs-vsctl set Open_vSwitch . other_config={}
ovs-vsctl set Open_vSwitch . other_config:dpdk-lcore-mask=0x1
ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x15554
ovs-vsctl set Interface dpdk0 options:n_rxq=2
ovs-vsctl set Interface dpdk1 options:n_rxq=2


echo "all done"

# sh boot_ovs_client.sh

# ovs-vsctl show
9b34b335-067e-493e-bc00-d8ba41e0c82d
    Bridge "ovsbr1"
        Port "vhost-user1"
            Interface "vhost-user1"
                type: dpdkvhostuserclient
                options: {vhost-server-path="/tmp/vhostuser1.sock"}
        Port "dpdk1"
            Interface "dpdk1"
                type: dpdk
                options: {dpdk-devargs="0000:04:00.1", n_rxq="2"}
        Port "ovsbr1"
            Interface "ovsbr1"
                type: internal
    Bridge "ovsbr0"
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal
        Port "dpdk0"
            Interface "dpdk0"
                type: dpdk
                options: {dpdk-devargs="0000:04:00.0", n_rxq="2"}
        Port "vhost-user0"
            Interface "vhost-user0"
                type: dpdkvhostuserclient
                options: {vhost-server-path="/tmp/vhostuser0.sock"}


[3]
# modprobe vfio
# modprobe vfio-pci
# echo 4 >  /sys/devices/system/node/node0/hugepages/hugepages-1048576kB/nr_hugepages
# dpdk-devbind --bind=vfio-pci 0000:06:00.0
# dpdk-devbind --bind=vfio-pci 0000:07:00.0

# /usr/bin/testpmd \
-l 1,2,3,4,5 \
-n 4 \
-d /usr/lib64/librte_pmd_virtio.so.1 \
-w 0000:06:00.0 -w 0000:07:00.0 \
-- \
--nb-cores=4 \
--disable-hw-vlan \
-i \
--disable-rss \
--rxq=2 --txq=2

testpmd> start

[5]
# /usr/bin/testpmd \
-l 1,2,3,4,5 \
-n 4 \
-d /usr/lib64/librte_pmd_virtio.so.1 \
-w 0000:06:00.0 -w 0000:07:00.0 \
-- \
--nb-cores=4 \
--disable-hw-vlan \
-i \
--disable-rss \
--rxq=2 --txq=2

testpmd> start

Additional info:

Comment 2 Pei Zhang 2018-07-30 06:35:59 UTC
Additional info:

1. Without enabling vIOMMU support, ovs works well. So this issue only happens when enabling vIOMMU.


2. This should not be a regression bug. As testing with below old versions, still hit same issue.

openvswitch-2.9.0-15.el7fdp.x86_64   fail
openvswitch-2.9.0-1.el7fdp.x86_64    fail

Comment 3 Maxime Coquelin 2018-08-01 10:48:58 UTC
Hi Pei,

I tried to reproduce with using testpmd on host instead of OVS,
but it does not crash, even when generating traffic from host.

Could you generate a coredump of OVS? I think it would help to
understand what is happening.

Thanks

Comment 4 Maxime Coquelin 2018-08-01 14:17:02 UTC
I tried again with OVS but still does not reproduce:
openvswitch-2.9.0-47.el7fdp.2.x86_64
qemu-kvm-rhev-2.12.0-8.el7.x86_64
kernel-3.10.0-927.el7.x86_64
dpdk-17.11-11.el7.x86_64

Do you have traffic generator started to reproduce?

Comment 5 Pei Zhang 2018-08-02 08:08:19 UTC
(In reply to Maxime Coquelin from comment #3)
> Hi Pei,
> 
> I tried to reproduce with using testpmd on host instead of OVS,
> but it does not crash, even when generating traffic from host.
> 
> Could you generate a coredump of OVS? I think it would help to
> understand what is happening.
> 
> Thanks

Hi Maxime,

Here is the coredump info of OVS:

http://pastebin.test.redhat.com/626299


(In reply to Maxime Coquelin from comment #4)
> I tried again with OVS but still does not reproduce:
> openvswitch-2.9.0-47.el7fdp.2.x86_64
> qemu-kvm-rhev-2.12.0-8.el7.x86_64
> kernel-3.10.0-927.el7.x86_64
> dpdk-17.11-11.el7.x86_64
> 
> Do you have traffic generator started to reproduce?

This issue can be reproduced without traffic generator.

In my today's testing, ovs core dump issue is not 100% reproduced. As sometimes qemu crash, sometimes ovs crash(ovs and qemu are not crashed at same time, every time only one of them crash). For qemu crash issue, it should be bug[1].

[1]Bug 1552978 - qemu crash during throughput testing over ovs+dpdk+vhost-user


Thanks,
Pei

Comment 6 Maxime Coquelin 2018-08-02 17:34:23 UTC
Hi Pei,

I managed to reproduce the OVS crash on your setup.
The reason of the crash is that on Virtio PMD second probe,
VHOST_USER_SET_MEM_TABLE request is sent again, but the IOTLB cache
is not flushed and so it contains invalid IOTLB entries pointing
to unmapped pages in vhost-user process address space.

I posted the fix upstream [0], and tested it on you setup.
I generated test RPMs in case you are willing to try[1].

About the QEMU crash, I managed to reproduce it once, and I confirm it
looks like Bz1552978 (and Bz1547940).

Thanks,
Maxime

[0]: http://patches.dpdk.org/patch/43534/
[1]: http://file.cdg.redhat.com/~mcoqueli/bz1609643/

Comment 7 Pei Zhang 2018-08-03 14:40:53 UTC
(In reply to Maxime Coquelin from comment #6)
> Hi Pei,
> 
> I managed to reproduce the OVS crash on your setup.
> The reason of the crash is that on Virtio PMD second probe,
> VHOST_USER_SET_MEM_TABLE request is sent again, but the IOTLB cache
> is not flushed and so it contains invalid IOTLB entries pointing
> to unmapped pages in vhost-user process address space.
> 
> I posted the fix upstream [0], and tested it on you setup.
> I generated test RPMs in case you are willing to try[1]. 
> About the QEMU crash, I managed to reproduce it once, and I confirm it
> looks like Bz1552978 (and Bz1547940).
> 
> Thanks,
> Maxime
> 
> [0]: http://patches.dpdk.org/patch/43534/
> [1]: http://file.cdg.redhat.com/~mcoqueli/bz1609643/

Maxime, thank you for handling this issue so quickly. Now this bug can not be reproduced any more with above versions.

Tried above steps on 2 different hosts, each for 5 times, ovs always work well. So this issue has been fixed very well. 

The QEMU crash issue is hard to reproduce, however it still can be reproduced even when testing with above openvswitch-2.9.0-58.bz1609643.el7fdn.x86_64. I'll add coredump info in Bz1552978.  


Best Regards,
Pei

Comment 8 Maxime Coquelin 2018-08-14 09:57:30 UTC
Patch applied in usptream's master:

commit af53db486792f3d864c9a30dc13ee12402994640
Author: Maxime Coquelin <maxime.coquelin>
Date:   Thu Aug 2 19:21:22 2018 +0200

    vhost: flush IOTLB cache on new mem table handling
    
    IOTLB entries contain the host virtual address of the guest
    pages. When receiving a new VHOST_USER_SET_MEM_TABLE request,
    the previous regions get unmapped, so the IOTLB entries, if any,
    will be invalid. It does cause the vhost-user process to
    segfault.
    
    This patch introduces a new function to flush the IOTLB cache,
    and call it as soon as the backend handles a VHOST_USER_SET_MEM
    request.
    
    Fixes: 69c90e98f483 ("vhost: enable IOMMU support")
    Cc: stable
    
    Signed-off-by: Maxime Coquelin <maxime.coquelin>
    Reviewed-by: Tiwei Bie <tiwei.bie>
    Reviewed-by: Jens Freimann <jfreimann>

Comment 10 Pei Zhang 2018-08-16 07:56:54 UTC
Verification:


Versions:
openvswitch-2.9.0-59.el7fdn.x86_64
3.10.0-933.el7.x86_64
tuned-2.9.0-1.el7.noarch
qemu-kvm-rhev-2.12.0-10.el7.x86_64
dpdk-17.11-10.el7fdb.x86_64
libvirt-4.5.0-6.el7.x86_64


Steps:
1. Do same testings as Description, ovs keeps working well. 3/3 PASS

2. Do live migration with vIOMMU, ovs keeps working well. 10/10 PASS


So this issue has been fixed very well.

Comment 12 Pei Zhang 2018-09-29 08:41:37 UTC
Move to 'VERIFIED' as comment 10.

Comment 14 errata-xmlrpc 2018-11-05 14:59:03 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2018:3500


Note You need to log in before you can comment on or make changes to this bug.