- 26 9月, 2018 9 次提交
-
-
由 Marc Hartmayer 提交于
Use the mnemonic macros of libdbus for 1 (TRUE) and 0 (FALSE). Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Marc Hartmayer 提交于
Report a debug message if dbus_watch_handle() returns FALSE. dbus_watch_handle() returns FALSE if there wasn't enough memory for reading or writing. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Marc Hartmayer 提交于
As documented at https://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#ga2522ac5075dfe0a1535471f6e045e1ee the creator of a non-shared D-Bus connection has to release the last reference after closing for freeing. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NStefan Zimmermann <stzi@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Marc Hartmayer 提交于
Grab a ref for info->bus (a DBus connection) as long as the while loop is running. With the grabbed reference it is ensured that info->bus isn't freed as long as the while loop is executed. This is necessary as it's allowed to drop the last ref for the bus connection in a handler. There was already a bug of this kind in libdbus itself: https://bugs.freedesktop.org/show_bug.cgi?id=15635. Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
The only place where VIR_DOMAIN_EVENT_RESUMED should be generated is the RESUME event handler to make sure we don't generate duplicate events or state changes. In the worse case the duplicity can revert or cover changes done by other event handlers. For example, after QEMU sent RESUME, BLOCK_IO_ERROR, and STOP events we could happily mark the domain as running and report VIR_DOMAIN_EVENT_RESUMED to registered clients. https://bugzilla.redhat.com/show_bug.cgi?id=1612943Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
Thanks to the previous commit the RESUME event handler knows what reason should be used when changing the domain state to VIR_DOMAIN_RUNNING, but the emitted VIR_DOMAIN_EVENT_RESUMED event still uses a generic VIR_DOMAIN_EVENT_RESUMED_UNPAUSED detail. Luckily, the event detail can be easily deduced from the running reason, which saves us from having to pass one more value to the handler. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
Whenever we get the RESUME event from QEMU, we change the state of the affected domain to VIR_DOMAIN_RUNNING with VIR_DOMAIN_RUNNING_UNPAUSED reason. This is fine if the domain is resumed unexpectedly, but when we sent "cont" to QEMU we usually have a better reason for the state change. The better reason is used in qemuProcessStartCPUs which also sets the domain state to running if qemuMonitorStartCPUs reports success. Thus we may end up with two state updates in a row, but the final reason is correct. This patch is a preparation for dropping the state change done in qemuMonitorStartCPUs for which we need to pass the actual running reason to the RESUME event handler and use it there instead of VIR_DOMAIN_RUNNING_UNPAUSED. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
This patch replaces some rather generic VIR_DOMAIN_RUNNING_UNPAUSED reasons when changing domain state to running with more specific ones. All of them are done when libvirtd reconnects to an existing domain after being restarted and sees an unfinished migration or save. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
由 Jiri Denemark 提交于
VIR_DOMAIN_EVENT_RESUMED_FROM_SNAPSHOT was defined but not used anywhere in our event generation code. This fixes qemuDomainRevertToSnapshot to properly report why the domain was resumed. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
-
- 25 9月, 2018 31 次提交
-
-
由 Mark Asselstine 提交于
A deadlock situation can occur when autostarting a LXC domain 'guest' due to two threads attempting to take opposing locks while holding opposing locks (AB BA problem). Thread A takes and holds the 'vm' lock while attempting to take the 'client' lock, meanwhile, thread B takes and holds the 'client' lock while attempting to take the 'vm' lock. The potential for this can be seen as follows: Thread A: virLXCProcessAutostartDomain (takes vm lock) --> virLXCProcessStart --> virLXCProcessConnectMonitor --> virLXCMonitorNew --> virNetClientSetCloseCallback (wants client lock) Thread B: virNetClientIncomingEvent (takes client lock) --> virNetClientIOHandleInput --> virNetClientCallDispatch --> virNetClientCallDispatchMessage --> virNetClientProgramDispatch --> virLXCMonitorHandleEventInit --> virLXCProcessMonitorInitNotify (wants vm lock) Since these threads are scheduled independently and are preemptible it is possible for the deadlock scenario to occur where each thread locks their first lock but both will fail to get their second lock and just spin forever. You get something like: virLXCProcessAutostartDomain (takes vm lock) --> virLXCProcessStart --> virLXCProcessConnectMonitor --> virLXCMonitorNew <...> virNetClientIncomingEvent (takes client lock) --> virNetClientIOHandleInput --> virNetClientCallDispatch --> virNetClientCallDispatchMessage --> virNetClientProgramDispatch --> virLXCMonitorHandleEventInit --> virLXCProcessMonitorInitNotify (wants vm lock but spins) <...> --> virNetClientSetCloseCallback (wants client lock but spins) Neither thread ever gets the lock it needs to be able to continue while holding the lock that the other thread needs. The actual window for preemption which can cause this deadlock is rather small, between the calls to virNetClientProgramNew() and execution of virNetClientSetCloseCallback(), both in virLXCMonitorNew(). But it can be seen in real world use that this small window is enough. By moving the call to virNetClientSetCloseCallback() ahead of virNetClientProgramNew() we can close any possible chance of the deadlock taking place. There should be no other implications to the move since the close callback (in the unlikely event was called) will spin on the vm lock. The remaining work that takes place between the old call location of virNetClientSetCloseCallback() and the new location is unaffected by the move. Signed-off-by: NMark Asselstine <mark.asselstine@windriver.com> Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Pavel Hrdina 提交于
With the introduction of cgroup v2 there are new names used with cgroups based on which version is used: - legacy: cgroup v1 - unified: cgroup v2 - hybrid: cgroup v1 and cgroup v2 Let's use 'legacy' instead of 'cgroupv1' or 'controllers' in our code. Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
They all need virCgroupV1GetMemoryUnlimitedKB() so it's easier to move them in one commit. Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-
由 Pavel Hrdina 提交于
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com> Reviewed-by: NJán Tomko <jtomko@redhat.com> Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
-