Bug 1599973
Summary: | libvirtd crashed during stop if there is a guest set filterref in guest vNIC | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Luyao Huang <lhuang> |
Component: | libvirt | Assignee: | John Ferlan <jferlan> |
Status: | CLOSED ERRATA | QA Contact: | Luyao Huang <lhuang> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 7.6 | CC: | dyuan, xuzhang, yafu, yalzhang |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | libvirt-4.5.0-5.el7 | Doc Type: | No Doc Update |
Doc Text: |
undefined
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2018-10-30 09:57:31 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Luyao Huang
2018-07-11 04:47:42 UTC
A patch to resolve is posted upstream: https://www.redhat.com/archives/libvir-list/2018-July/msg01523.html The patch is now pushed: commit 5229494b01acf97dbc6f3028e9718667e9e1426a Author: John Ferlan <jferlan> Date: Fri Jul 20 17:44:08 2018 -0400 nwfilter: Resolve SEGV for NWFilter Snoop processing ... Commit id fca9afa08 changed the @req->ifname to use @req->binding->portdevname fillingin the @req->binding in a similar way that @req->ifname would have been filled in during virNWFilterDHCPSnoopReq processing. However, in doing so it did not take into account some code paths where the @req->binding should be checked instead of @req->binding->portdevname. These checks led to SEGVs in some cases during libvirtd reload processing in virNWFilterSnoopRemAllReqIter (for stop during nwfilterStateCleanup processing) and virNWFilterSnoopReqLeaseDel (for start during nwfilterStateInitialize processing). In particular, when reading the nwfilter.leases file a new @req is created, but the @req->binding is not filled in. That's left to virNWFilterDHCPSnoopReq processing which checks if the @req already exists in the @virNWFilterSnoopState.snoopReqs hash table after adding a virNWFilterSnoopState.ifnameToKey entry for the @req->binding->portdevname by a @ref->ikey value. NB: virNWFilterSnoopIPLeaseInstallRule and virNWFilterDHCPSnoopThread do not need the req->binding check since they can only be called after the filter->binding is created/assigned. Signed-off-by: John Ferlan <jferlan> ACKed-by: Michal Privoznik <mprivozn> $ git describe 5229494b01acf97dbc6f3028e9718667e9e1426a v4.5.0-297-g5229494b01 $ Verify this bug on libvirt-4.5.0-6.el7.x86_64: 1. prepare a running guest with vNIC xml like this: <interface type='network'> <mac address='52:54:00:2c:76:c5'/> <source network='default' bridge='virbr0'/> <target dev='vnet0'/> <model type='rtl8139'/> <filterref filter='clean-traffic'> <parameter name='CTRL_IP_LEARNING' value='dhcp'/> </filterref> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </interface> 2. check nwfilter.leases file: # cat /run/libvirt/network/nwfilter.leases 1534387047 4d73262f-35a7-437e-96ad-e5246aac79ee-52:54:00:2c:76:c5 192.168.122.238 192.168.122.1 1534387048 4d73262f-35a7-437e-96ad-e5246aac79ee-52:54:00:2c:76:c5 192.168.122.238 192.168.122.1 1534388701 4d73262f-35a7-437e-96ad-e5246aac79ee-52:54:00:2c:76:c5 192.168.122.238 192.168.122.1 1534389984 4d73262f-35a7-437e-96ad-e5246aac79ee-52:54:00:2c:76:c5 192.168.122.238 192.168.122.1 1534391426 4d73262f-35a7-437e-96ad-e5246aac79ee-52:54:00:2c:76:c5 192.168.122.238 192.168.122.1 1534392838 4d73262f-35a7-437e-96ad-e5246aac79ee-52:54:00:2c:76:c5 192.168.122.238 192.168.122.1 3. use gdb attach running libvirtd and open another terminal to stop libvirtd, cannot find crash report 4. start libvirtd with gdb and check there is no crash report 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:3113 |