In order to mirror a server with per-object filtering, the client
needs to track which server callbackID is servicing the client
callback. This patch introduces the notion of a serverID, as
well as the plumbing to use it for network events, although the
actual complexity of using per-object filtering in the remote
driver is deferred to a later patch.
* src/conf/object_event.h (virObjectEventStateEventID): Add parameter.
(virObjectEventStateQueueRemote, virObjectEventStateSetRemote):
New prototypes.
(virObjectEventStateRegisterID): Move...
* src/conf/object_event_private.h: ...here, and add parameter.
(_virObjectEvent): Add field.
* src/conf/network_event.h (virNetworkEventStateRegisterClient): New
prototype.
* src/conf/object_event.c (_virObjectEventCallback): Add field.
(virObjectEventStateSetRemote): New function.
(virObjectEventStateQueue): Make wrapper around...
(virObjectEventStateQueueRemote): New function.
(virObjectEventCallbackListCount): Tweak return count when remote
id matching is used.
(virObjectEventCallbackLookup, virObjectEventStateRegisterID):
Tweak registration when remote id matching will be used.
(virObjectEventNew): Default to no remote id.
(virObjectEventCallbackListAddID): Likewise, but set remote id
when one is available.
(virObjectEventCallbackListRemoveID)
(virObjectEventCallbackListMarkDeleteID): Adjust return value when
remote id was set.
(virObjectEventStateEventID): Query existing id.
(virObjectEventDispatchMatchCallback): Require matching event id.
(virObjectEventStateCallbackID): Adjust caller.
* src/conf/network_event.c (virNetworkEventStateRegisterClient): New
function.
(virNetworkEventStateRegisterID): Update caller.
* src/conf/domain_event.c (virDomainEventStateRegister)
(virDomainEventStateRegisterID): Update callers.
* src/remote/remote_driver.c
(remoteConnectNetworkEventRegisterAny)
(remoteConnectNetworkEventDeregisterAny)
(remoteConnectDomainEventDeregisterAny): Likewise.
(remoteEventQueue): Hoist earlier to avoid forward declaration,
and add parameter. Adjust all callers.
* src/libvirt_private.syms (conf/object_event.h): Drop function.
Signed-off-by: Eric Blake <eblake@redhat.com>
Right now, the daemon side of RPC events is hard-coded to at most
one callback per eventID. But when there are hundreds of domains
or networks coupled and multiple conections, then sending every
event to every connection that wants an event, even for the
connections that only care about events for a particular object,
is inefficient. In order to track more than one callback in the
server, we need to store callbacks by more than just their
eventID. This patch rearranges the daemon side to store network
callbacks in a dynamic array, which can eventually be used for
multiple callbacks of the same eventID, although actual behavior
is unchanged without further patches to the RPC protocol. For
ease of review, domain events are saved for a later patch, as
they touch more code.
While at it, fix a bug where a malicious client could send a
negative eventID to cause network event registration to access
outside of array bounds (thankfully not a CVE, since domain
events were already doing the bounds check, and since network
events have not been released).
* daemon/libvirtd.h (daemonClientPrivate): Alter the tracking of
network events.
* daemon/remote.c (daemonClientEventCallback): New struct.
(remoteEventCallbackFree): New function.
(remoteClientInitHook, remoteRelayNetworkEventLifecycle)
(remoteClientFreeFunc)
(remoteDispatchConnectNetworkEventRegisterAny): Track network
callbacks differently.
(remoteDispatchConnectNetworkEventDeregisterAny): Enforce bounds.
Signed-off-by: Eric Blake <eblake@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1047659
If a VM dies very early during an attempted connect to the guest agent
while the locks are down the domain monitor object will be freed. The
object is then accessed later as any failure during guest agent startup
isn't considered fatal.
In the current upstream version this doesn't lead to a crash as
virObjectLock called when entering the monitor in
qemuProcessDetectVcpuPIDs checks the pointer before attempting to
dereference (lock) it. The NULL pointer is then caught in the monitor
helper code.
Before the introduction of virObjectLockable - observed on 0.10.2 - the
pointer is locked directly via virMutexLock leading to a crash.
To avoid this problem we need to differentiate between the guest agent
not being present and the VM quitting when the locks were down. The fix
reorganizes the code in qemuConnectAgent to add the check and then adds
special handling to the callers.
While working on v1.0.5-maint (the branch in use on Fedora 19)
with the host at Fedora 20, I got a failure in virstoragetest.
I traced it to the fact that we were using qemu-img to create a
qcow2 file, but qemu-img changed from creating v2 files by
default in F19 to creating v3 files in F20. Rather than leaving
it up to qemu-img, it is better to write the test to force
testing of BOTH file formats (better code coverage and all).
This patch alone does not fix all the failures in v1.0.5-maint;
for that, we must decide to either teach the older branch to
understand v3 files, or to reject them outright as unsupported.
But for upstream, making the test less dependent on changing
qemu-img defaults is always a good thing.
* tests/virstoragetest.c (testPrepImages): Simplify creation of
raw file; check if qemu supports compat and if so use it.
Signed-off-by: Eric Blake <eblake@redhat.com>
Mitre tried to assign us two separate CVEs for the fix for
https://bugzilla.redhat.com/show_bug.cgi?id=1047577, on the
grounds that the fixes were separated by more than an hour
and thus triggered different hourly snapshots. But we
explicitly do NOT want to treat transient security bugs as
CVEs if they can only be triggered by patches in libvirt.git
but where the problem is cleaned up before a formal release.
Meanwhile, I noticed that while our wiki mentioned maintenance
branches and releases, our formal documentation did not.
* docs/downloads.html.in: Contrast hourly snapshots with
maintenance branches.
Signed-off-by: Eric Blake <eblake@redhat.com>
For a "newfd1" the coverity tools thinks that the fd is closed in
a "virCommandPassFD", but with "flags == 0" it cannot be closed.
The code itself is ok, but coverity tool thinks that there is
"double_close" of the "newfd1" and to prevent showing this error
we simply add a comment before the proper close.
This has been found by coverity.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Strings "file" and "context" may not be freed if "VIR_EXPAND_N" fails
and it leads into memory leak.
This has been found by coverity.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
A "xmlstr" string may not be assigned into a "doc" pointer and it
could cause memory leak. To fix it if the "doc" pointer is NULL and
the "xmlstr" string is not assigned we should free it.
This has been found by coverity.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
There could be a memory leak caused by "managed_system" string, if any
error occurs before "managed_system" is assigned into
"phyp_driver->managed_system". The "managed_system" string wouldn't be
freed at all. The better way is to free the "managed_system" instead
of the one assigned in the "phyp_driver".
This has been found by coverity.
Pointed out by John, that the "phyp_driver->xmlopt" needs to be
unreferenced as well.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: John Ferlan <jferlan@redhat.com>
If there is no error while executing a function "openvzParseBarrierLimit"
a "str" string where is duplicate of a "value" string isn't freed and it
leads into memory leak.
This has been found by coverity.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
I ran 'git add .' for a patch in progress, while in the middle
of running 'make check' to test my work, and was surprised when
it picked up some files I wasn't expecting.
* .gitignore: Ignore *.pem.
Signed-off-by: Eric Blake <eblake@redhat.com>
While running objecteventtest, it was found that valgrind pointed out the
following memory leak:
==125== 538 (56 direct, 482 indirect) bytes in 1 blocks are definitely lost in loss record 216 of 226
==125== at 0x4A06B6F: calloc (vg_replace_malloc.c:593)
==125== by 0x4C65D8D: virAllocVar (viralloc.c:558)
==125== by 0x4C9F055: virObjectNew (virobject.c:190)
==125== by 0x4D2B2E8: virGetDomain (datatypes.c:220)
==125== by 0x4D79180: testDomainDefineXML (test_driver.c:2962)
==125== by 0x4D4977D: virDomainDefineXML (libvirt.c:8512)
==125== by 0x4029C2: testDomainCreateXMLMixed (objecteventtest.c:226)
==125== by 0x403A21: virtTestRun (testutils.c:138)
==125== by 0x4021C2: mymain (objecteventtest.c:549)
==125== by 0x4040C2: virtTestMain (testutils.c:593)
==125== by 0x341F421A04: (below main) (libc-start.c:225)
Signed-off-by: Ján Tomko <jtomko@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1047577
When writing commit 173c291, I missed the fact virNetServerClientClose
unlocks the client object before actually clearing client->sock and thus
it is possible to hit a window when client->keepalive is NULL while
client->sock is not NULL. I was thinking client->sock == NULL was a
better check for a closed connection but apparently we have to go with
client->keepalive == NULL to actually fix the crash.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
On my Fedora 20 box with mingw cross-compiler, the build failed with:
../../src/rpc/virnetclient.c: In function 'virNetClientSetTLSSession':
../../src/rpc/virnetclient.c:745:14: error: unused variable 'oldmask' [-Werror=unused-variable]
sigset_t oldmask, blockedsigs;
^
I traced it to the fact that mingw64-winpthreads installs a header
that does #define pthread_sigmask(...) 0, which means any argument
only ever passed to pthread_sigmask is reported as unused. This
patch works around the compilation failure, with behavior no worse
than what mingw already gives us regarding the function being a
no-op.
* configure.ac (pthread_sigmask): Probe for broken mingw macro.
* src/util/virutil.h (pthread_sigmask): Rewrite to something that
avoids unused variables.
Signed-off-by: Eric Blake <eblake@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1047577
When a client closes its connection to libvirtd early during
virConnectOpen, more specifically just after making
REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call to check if
VIR_DRV_FEATURE_PROGRAM_KEEPALIVE is supported without even waiting for
the result, libvirtd may crash due to a race in keep-alive
initialization. Once receiving the REMOTE_PROC_CONNECT_SUPPORTS_FEATURE
call, the daemon's event loop delegates it to a worker thread. In case
the event loop detects EOF on the connection and calls
virNetServerClientClose before the worker thread starts to handle
REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call, client->keepalive will be
disposed by the time virNetServerClientStartKeepAlive gets called from
remoteDispatchConnectSupportsFeature. Because the flow is common for
both authenticated and read-only connections, even unprivileged clients
may cause the daemon to crash.
To avoid the crash, virNetServerClientStartKeepAlive needs to check if
the connection is still open before starting keep-alive protocol.
Every libvirt release since 0.9.8 is affected by this bug.
Any test suite which involves a virDomainDefPtr should
call virDomainDefCheckABIStability with itself just as
a basic sanity check that the identity-comparison always
succeeds. This would have caught the recent NULL pointer
access crash.
Make sure we cope with def->name being NULL since the
VMWare config parser produces NULL names.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
When idmap was added to LXC, we forgot to cover it in the testsuite.
The schema was missing an <element> layer, and as a result,
virt-xml-validate was failing on valid dumpxml output.
Reported by Eduard - Gabriel Munteanu on IRC.
* docs/schemas/domaincommon.rng (idmap): Include <idmap> element,
and support interleaves.
* tests/lxcxml2xmldata/lxc-idmap.xml: New file.
* tests/lxcxml2xmltest.c (mymain): Test it.
Signed-off-by: Eric Blake <eblake@redhat.com>
Ever since commit 61ac8ce, Coverity complained about
remoteNetworkBuildEventLifecycle not checking for NULL failure
to build an event, compared to other calls in the code base.
But the problem is latent from copy and paste; all 17 of our
remote*BuildEvent* functions in remote_driver.c have the same
issue - if an OOM causes an event to not be built, we happily
pass NULL to remoteEventQueue(), but that function has marked
event as a nonnull parameter. We were getting lucky (the
event queue's first use of the event happened to be a call to
virIsObjectClass(), which acts gracefully on NULL, so there
was no way to crash); but this is a latent bug waiting to bite
us due to the disregard for the nonnull attribute, as well as
a waste of resources in the event queue. Better is to just
refuse to queue NULL. The discard is silent, since the problem
only happens on OOM, and since events are already best effort -
if we fail to get an event, it's not like we have any memory
left to report the issue, nor any idea of who would benefit
from knowing we couldn't create or queue the event.
* src/remote/remote_driver.c (remoteEventQueue): Ignore NULL event.
Signed-off-by: Eric Blake <eblake@redhat.com>
Our fixes for CVE-2013-4400 were so effective at "fixing" bugs
in virt-login-shell that we ended up fixing it into a useless
do-nothing program.
Commit 3e2f27e1 picked the name LIBVIRT_SETUID_RPC_CLIENT for
the witness macro when we are doing secure compilation. But
commit 9cd6a57d checked whether the name IN_VIRT_LOGIN_SHELL,
from an earlier version of the patch series, was defined; with
the net result that virt-login-shell invariably detected that
it was setuid and failed virInitialize.
Commit b7fcc799 closed all fds larger than stderr, but in the
wrong place. Looking at the larger context, we mistakenly did
the close in between obtaining the set of namespace fds, then
actually using those fds to switch namespace, which means that
virt-login-shell will ALWAYS fail.
This is the minimal patch to fix the regressions, although
further patches are also worth having to clean up poor
semantics of the resulting program (for example, it is rude to
not pass on the exit status of the wrapped program back to the
invoking shell).
* tools/virt-login-shell.c (main): Don't close fds until after
namespace swap.
* src/libvirt.c (virGlobalInit): Use correct macro.
Signed-off-by: Eric Blake <eblake@redhat.com>
The existing check of domain snapshots validated that they
point to a domain, but did not validate that the domain
points to a connection, even though any errors blindly assume
the connection is valid. On the other hand, as mentioned in
commit 6e130ddc, any valid domain is already tied to a valid
connection, and VIR_IS_SNAPSHOT vs. VIR_IS_DOMAIN_SNAPSHOT
makes no real difference; it's best to just validate the chain
of all three. For consistency with previous patches, continue
the trend of using a common macro. For now, we don't need
virCheckDomainSnapshotGoto().
* src/datatypes.h (virCheckDomainSnapshotReturn): New macro.
(VIR_IS_SNAPSHOT, VIR_IS_DOMAIN_SNAPSHOT):
Drop unused macros.
* src/libvirt.c: Use macro throughout.
(virLibDomainSnapshotError): Drop unused macro.
Signed-off-by: Eric Blake <eblake@redhat.com>
While all errors related to invalid nwfilters appeared to be
consistent, we might as well continue the trend of using a
common macro. As in commit 6e130ddc, the difference between
VIR_IS_NWFILTER and VIR_IS_CONNECTED_NWFILTER is moot, since
reference counting means any valid nwfilter is also tied to
a valid connection. For now, we don't need virCheckNWFilterGoto().
* src/datatypes.h (virCheckNWFilterReturn): New macro.
(VIR_IS_NWFILTER, VIR_IS_CONNECTED_NWFILTER): Drop unused macros.
* src/libvirt.c: Use macro throughout.
(virLibNWFilterError): Drop unused macro.
Signed-off-by: Eric Blake <eblake@redhat.com>
For streams validation, we weren't consistent on whether to
use VIR_FROM_NONE or VIR_FROM_STREAMS. Furthermore, in many
API, we want to ensure that a stream is tied to the same
connection as the other object we are operating on; while
other API failed to validate the stream at all. And the
difference between VIR_IS_STREAM and VIR_IS_CONNECTED_STREAM
is moot; as in commit 6e130ddc, we know that reference
counting means a valid stream will always be tied to a valid
connection. Similar to previous patches, use a common macro
to make it nicer.
* src/datatypes.h (virCheckStreamReturn, virCheckStreamGoto):
New macros.
(VIR_IS_STREAM, VIR_IS_CONNECTED_STREAM): Drop unused macros.
* src/libvirt.c: Use macro throughout.
(virLibStreamError): Drop unused macro.
Signed-off-by: Eric Blake <eblake@redhat.com>
While all errors related to invalid secrets appeared to be
consistent, we might as well continue the trend of using a
common macro. Just as in commit 6e130ddc, the difference
between VIR_IS_SECRET and VIR_IS_CONNECTED_SECRET is moot
(due to reference counting, any valid secret must be tied to
a valid domain). For now, we don't need virCheckSecretGoto().
* src/datatypes.h (virCheckSecretReturn): New macro.
(VIR_IS_SECRET, VIR_IS_CONNECTED_SECRET): Drop unused macros.
* src/libvirt.c: Use macro throughout.
(virLibSecretError): Drop unused macro.
Signed-off-by: Eric Blake <eblake@redhat.com>
While all errors related to invalid node device appeared to be
consistent, we might as well continue the trend of using a
common macro. For now, we don't need virCheckNodeDeviceGoto().
* src/datatypes.h (virCheckNodeDeviceReturn): New macro.
(VIR_IS_NODE_DEVICE, VIR_IS_CONNECTED_NODE_DEVICE): Drop
unused macros.
* src/libvirt.c: Use macro throughout.
(virLibNodeDeviceError): Drop unused macro.
Signed-off-by: Eric Blake <eblake@redhat.com>
The commit cad3cf9a95 introduced a crash
due to wrong order of parameters being passed to the function. When
deleting an element, the function decreased the iterator instead of
count and if listing volumes after that (or undefining the pool, NULL
was being dereferenced.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
For storage volume validation, we weren't consistent on
whether to use VIR_FROM_NONE or VIR_FROM_STORAGE. Similar
to previous patches, use a common macro to make it nicer.
Furthermore, just as in commit 6e130ddc, the difference
between VIR_IS_STORAGE_VOL and VIR_IS_CONNECTED_STORAGE_VOL
is moot (due to reference counting, any valid volume must
be tied to a valid connection).
virStorageVolCreateXMLFrom allows cross-connection cloning,
where the error is reported against the connection of the
destination pool.
* src/datatypes.h (virCheckStorageVolReturn)
(virCheckStorageVolGoto): New macros.
(VIR_IS_STORAGE_VOL, VIR_IS_CONNECTED_STORAGE_VOL): Drop
unused macros.
* src/libvirt.c: Use macro throughout.
(virLibStorageVolError): Drop unused macro.
Signed-off-by: Eric Blake <eblake@redhat.com>
This basically reverts commit ba64b97134
"libxl: Allow libxl to set NIC devid". However assigning devid's
before calling libxlMakeNic does not work as that is calling
libxl_device_nic_init which sets it back to -1.
Right now auto-assignment only works in the hotplug case. But even if
that would be fixed at some point (if that is possible at all), this
would add a weird dependency between Xen and libvirt versions.
The change here should accept any auto-assignment that makes it into
libxl_device_nic_init. My understanding is that a caller always is
allowed to make the devid choice itself. And assuming libxlMakeNicList
is only used on domain creation, a sequential numbering should be ok.
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
virStoragePoolBuild reported an invalid pool as if it were an
invalid network. Likewise, we weren't consistent on whether to
use VIR_FROM_NONE or VIR_FROM_STORAGE. Similar to previous
patches, use a common macro to make it nicer. Furthermore, just
as in commit 6e130ddc, the difference between VIR_IS_STORAGE_POOL
and VIR_IS_CONNECTED_STORAGE_POOL is moot (due to reference
counting, any valid pool must be tied to a valid connection).
For now, we don't need virCheckStoragePoolGoto().
* src/datatypes.h (virCheckStoragePoolReturn): New macro.
(VIR_IS_STORAGE_POOL, VIR_IS_CONNECTED_STORAGE_POOL): Drop
unused macros.
* src/libvirt.c: Use macro throughout.
(virLibStoragePoolError): Drop unused macro.
Signed-off-by: Eric Blake <eblake@redhat.com>
There is no easy way to test authentication against libvirt. This
commit modifies the test driver to allow simple username/password
authentication.
You modify the test XML by adding:
<node>
...
<auth>
<user password="123456">rich</user>
<user>jane</user>
</auth>
</node>
If there are any /node/auth/user elements, then authentication is
required by the test driver (if none are present, then the test driver
will work as before and not require authentication).
In the example above, two phony users are added:
rich password: 123456
jane no password required
The test driver will demand a username. If the password attribute is
present (or if the username entered is wrong), then the password is
also asked for and checked:
$ virsh -c test://$(pwd)/testnode.xml list
Enter username for localhost: rich
Enter rich's password for localhost: ***
Id Name State
----------------------------------------------------
1 fv0 running
2 fc4 running
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
When checking for a valid interface, we weren't consistent on
whether we reported as VIR_FROM_NONE or VIR_FROM_INTERFACE.
Similar to previous patches, use a common macro to make it nicer.
Furthermore, just as in commit 6e130ddc, the difference between
VIR_IS_INTERFACE and VIR_IS_CONNECTED_INTERFACE is moot (due to
reference counting, any valid interface must be tied to a valid
connection). For now, we don't need virCheckInterfaceGoto().
* src/datatypes.h (virCheckInterfaceReturn): New macro.
(VIR_IS_INTERFACE, VIR_IS_CONNECTED_INTERFACE): Drop unused
macros.
* src/libvirt.c: Use macro throughout.
(virLibInterfaceError): Drop unused macro.
Signed-off-by: Eric Blake <eblake@redhat.com>
Commit cfd62c1 was incomplete; I found more cases where error
messages were being overwritten, and where the code between
the three registration/deregistration APIs was not consistent.
Since it is fairly easy to trigger an attempt to deregister an
unregistered object through public API, I also changed the error
message from VIR_ERR_INTERNAL_ERROR to VIR_ERR_INVALID_ARG.
* src/conf/object_event.c (virObjectEventCallbackListEventID):
Inline...
(virObjectEventStateEventID): ...into lone caller, and report
error on failure.
(virObjectEventCallbackListAddID, virObjectEventStateCallbackID)
(virObjectEventCallbackListRemoveID)
(virObjectEventCallbackListMarkDeleteID): Tweak error category.
* src/remote/remote_driver.c (remoteConnectDomainEventRegister):
Don't leak registration on failure.
(remoteConnectDomainEventDeregisterAny)
(remoteConnectNetworkEventDeregisterAny): Don't overwrite error.
Signed-off-by: Eric Blake <eblake@redhat.com>
When checking for a valid network, we weren't consistent on
whether we reported an invalid network or a connection. Similar
to previous patches such as commit 6e130ddc, the difference
between VIR_IS_NETWORK and VIR_IS_CONNECTED_NETWORK is moot (due
to reference counting, any valid network must be tied to a valid
connection). Use a common macro to make the error reporting
for invalid networks nicer.
* src/datatypes.h (virCheckNetworkReturn, virCheckNetworkGoto): New
macros.
(VIR_IS_NETWORK, VIR_IS_CONNECTED_NETWORK): Drop unused macros.
* src/libvirt.c: Use macro throughout.
(virLibNetworkError): Drop unused macro.
Signed-off-by: Eric Blake <eblake@redhat.com>
Like commit 94a26c7e from Eric Blake, the old fuzzy code should
be replaced by the new array management macros now.
And the type of scsi->count should be changed into "size_t", and
thus virSCSIDeviceListCount should return size_t instead, similar
for vir{PCI,USB}DeviceListCount.
the unix socket /var/run/libvirt/lxc/domain.sock is not created
under the selinux context which configured by <seclabel>.
If we try to connect the domain.sock under the selinux context
of domain in virtLXCProcessConnectMonitor,selinux will deny
this connect operation.
type=AVC msg=audit(1387953696.067:662): avc: denied { connectto } for pid=21206 comm="libvirtd" path="/usr/local/var/run/libvirt/lxc/systemd.sock" scontext=unconfined_u:system_r:svirt_lxc_net_t:s0:c770,c848 tcontext=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket
fix this problem by creating socket under selinux context of domain.
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1049529
The 'detach-disk' command in virsh used the active XML definition of a
domain even when attempting to remove a disk from the config only. If
the disk was only in the inactive definition the operation failed. Fix
this by using the inactive XML in case that only the config is affected.
https://bugzilla.redhat.com/show_bug.cgi?id=1049529
The legacy virDomainAttachDevice and virDomainDetachDevice operate only
on active domains. When a user specified --current flag with an inactive
domain the old API was used and reported an error. Fix it by calling the
new API if --current is specified explicitly.
The function checks for @conn to be valid and locks its mutex. Then, it
checks if callee is unregistering the same callback that he registered
previously. If this fails an error is reported and the control jumps to
'error' label. Here, if @conn has some errors (and it certainly does -
the one that's been just reported) the conn->mutex is locked again -
without any previous unlock:
Thread 1 (Thread 0x7fb500ef1800 (LWP 18982)):
#0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x00007fb4fd99ce56 in _L_lock_918 () from /lib64/libpthread.so.0
#2 0x00007fb4fd99ccaa in __GI___pthread_mutex_lock (mutex=0x7fb50153b670) at pthread_mutex_lock.c:64
#3 0x00007fb5007e574d in virMutexLock (m=m@entry=0x7fb50153b670) at util/virthreadpthread.c:85
#4 0x00007fb5007b198e in virDispatchError (conn=conn@entry=0x7fb50153b5e0) at util/virerror.c:594
#5 0x00007fb5008a3735 in virConnectUnregisterCloseCallback (conn=0x7fb50153b5e0, cb=cb@entry=0x7fb500f588e0 <vshCatchDisconnect>) at libvirt.c:21025
#6 0x00007fb500f5d690 in vshReconnect (ctl=ctl@entry=0x7fffff60e710) at virsh.c:328
#7 0x00007fb500f5dc50 in vshCommandRun (ctl=ctl@entry=0x7fffff60e710, cmd=0x7fb50152ca80) at virsh.c:1755
#8 0x00007fb500f5861b in main (argc=<optimized out>, argv=<optimized out>) at virsh.c:3393
And since the conn's mutex is not recursive, the virDispatchError will
never ever lock it successfully.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
