diff options
author | Luiz Capitulino <lcapitulino@redhat.com> | 2011-10-28 14:59:52 -0200 |
---|---|---|
committer | Anthony Liguori <aliguori@us.ibm.com> | 2011-11-01 11:50:12 -0500 |
commit | 1fdc11c36971e0d4eeb2ce817f7e520b2028c2f2 (patch) | |
tree | 37dee76f6f6bec93f7be3b90ae580c56412d90e7 /rules.mak | |
parent | 4f39d27fe4e8109ba9eb2983b27675f2ca6d3ecb (diff) |
Fix segfault on migration completion
A simple migration reproduces it:
1. Start the source VM with:
# qemu [...] -S
2. Start the destination VM with:
# qemu <source VM cmd-line> -incoming tcp:0:4444
3. In the source VM:
(qemu) migrate -d tcp:0:4444
4. The source VM will segfault as soon as migration completes (might not
happen in the first try)
What is happening here is that qemu_file_put_notify() can end up closing
's->file' (in which case it's also set to NULL). The call stack is rather
complex, but Eduardo helped tracking it to:
select loop -> migrate_fd_put_notify() -> qemu_file_put_notify() ->
buffered_put_buffer() -> migrate_fd_put_ready() ->
migrate_fd_completed() -> migrate_fd_cleanup().
To be honest, it's not completely clear to me in which cases 's->file'
is not closed (on error maybe)? But I doubt this fix will make anything
worse.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Diffstat (limited to 'rules.mak')
0 files changed, 0 insertions, 0 deletions