aboutsummaryrefslogtreecommitdiff
path: root/hw
diff options
context:
space:
mode:
authorPaolo Bonzini <pbonzini@redhat.com>2014-06-27 16:31:07 +0200
committerPaolo Bonzini <pbonzini@redhat.com>2014-07-09 18:17:08 +0200
commit30e5210a706ca6b52cbefa8b71e40ae614ffd6e5 (patch)
treeb5714afa10c11c42b4d190711f39468ff66e5ee1 /hw
parentf7f152458e953690f1c8025f507a26d554f6ee4d (diff)
watchdog: fix deadlock with -watchdog-action pause
qemu_clock_enable says: /* Disabling the clock will wait for related timerlists to stop * executing qemu_run_timers. Thus, this functions should not * be used from the callback of a timer that is based on @clock. * Doing so would cause a deadlock. */ and it indeed does: vm_stop uses qemu_clock_enable on QEMU_CLOCK_VIRTUAL and watchdogs are based on QEMU_CLOCK_VIRTUAL, and we get a deadlock. Use qemu_system_vmstop_request_prepare()/qemu_system_vmstop_request() instead; yet another alternative could be a BH. I checked other occurrences of vm_stop and they should not have this problem. RUN_STATE_IO_ERROR could in principle (it depends on the code in the drivers) but it has been fixed by commit 2bd3bce, "block: asynchronously stop the VM on I/O errors", 2014-06-05. Tested-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'hw')
-rw-r--r--hw/watchdog/watchdog.c6
1 files changed, 5 insertions, 1 deletions
diff --git a/hw/watchdog/watchdog.c b/hw/watchdog/watchdog.c
index 9f607d42bb..c307f9b57e 100644
--- a/hw/watchdog/watchdog.c
+++ b/hw/watchdog/watchdog.c
@@ -122,8 +122,12 @@ void watchdog_perform_action(void)
exit(0);
case WDT_PAUSE: /* same as 'stop' command in monitor */
+ /* In a timer callback, when vm_stop calls qemu_clock_enable
+ * you would get a deadlock. Bypass the problem.
+ */
+ qemu_system_vmstop_request_prepare();
qapi_event_send_watchdog(WATCHDOG_EXPIRATION_ACTION_PAUSE, &error_abort);
- vm_stop(RUN_STATE_WATCHDOG);
+ qemu_system_vmstop_request(RUN_STATE_WATCHDOG);
break;
case WDT_DEBUG: