From: Fiona Ebner <f.ebner@proxmox.com>
To: pve-devel@lists.proxmox.com, Mira Limbeck <m.limbeck@proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu] avoid segfault when aborting snapshot
Date: Tue, 2 Aug 2022 12:04:35 +0200 [thread overview]
Message-ID: <d8618a64-9eb7-4cee-012e-1b5e2f4b2aef@proxmox.com> (raw)
In-Reply-To: <e32943cb-55ba-2b92-ec32-e2f0874d2e35@proxmox.com>
Am 02.08.22 um 11:52 schrieb Mira Limbeck:
> On 7/26/22 14:25, Fiona Ebner wrote:
>> Reported in the community forum[0].
>>
>> For 6.1.0, there were a few changes to the coroutine-sleep API, but
>> the adaptations in f376b2b ("update and rebase to QEMU v6.1.0") made
>> a mistake.
>>
>> Currently, target_close_wait is NULL when passed to
>> qemu_co_sleep_ns_wakeable(), which further passes it to
>> qemu_co_sleep(), but there, it is dereferenced when trying to access
>> the 'to_wake' member:
>>
>>> Thread 1 "kvm" received signal SIGSEGV, Segmentation fault.
>>> qemu_co_sleep (w=0x0) at ../util/qemu-coroutine-sleep.c:57
>> To fix it, create a proper struct and pass its address instead. Also
>> call qemu_co_sleep_wake unconditionally, because the NULL check (for
>> the 'to_wake' member) is done inside the function itself.
>>
>> This patch is based on what the QEMU commits introducing the changes
>> to the coroutine-sleep API did to the callers in QEMU:
>> eaee072085 ("coroutine-sleep: allow qemu_co_sleep_wake that wakes
>> nothing")
>> 29a6ea24eb ("coroutine-sleep: replace QemuCoSleepState pointer with
>> struct in the API")
>>
>> [0]: https://forum.proxmox.com/threads/112130/
>>
>> Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
>> ---
>
> Tested-by: Mira Limbeck <m.limbeck@proxmox.com>
>
>
> Found a strange behavior when aborting the snapshot. It no longer
> crashes, but trying to snapshot the VM again leads to instant failure.
>
> After the failed snapshot, the next one works again. So some state
> doesn't seem to be cleaned up the first time.
Thanks for testing! This behavior was present even before 6.1.0, so not
related to the patch, but I wasn't entirely sure if it'd be fine to just
set the status to SAVE_STATE_DONE in qmp_savevm_end() after abort.
I'll take another look and send a follow-up. It's probably fine in case
the state file has been closed successfully, but I'll need to check the
users in qemu-server and test it.
prev parent reply other threads:[~2022-08-02 10:05 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-26 12:25 Fiona Ebner
2022-08-02 9:52 ` Mira Limbeck
2022-08-02 10:04 ` Fiona Ebner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d8618a64-9eb7-4cee-012e-1b5e2f4b2aef@proxmox.com \
--to=f.ebner@proxmox.com \
--cc=m.limbeck@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.