On 9/1/26 14:50, Denis V. Lunev wrote:
> On 9/1/26 14:23, Fiona Ebner wrote:
>> Should also go into stable I suppose?
>
> Unsure. We do not know real consequences, there are no reports.
> I found this problem by accident only testing migration with
> big trees a lot.
I came across the bug by accident while exploring the code.
It is easy to trigger with a plain -drive next to a detached -blockdev
node. If the last BlockBackend root is not monitor-owned, it is not on
monitor_bdrv_states, so bdrv_next_monitor_owned() returns NULL right
away and the second phase returns no node at all, not only those added
before it.
Reproducer:
qemu-img create -f qcow2 a.qcow2 64M
qemu-img create -f qcow2 b.qcow2 64M
qemu-system-x86_64 -S -nodefaults -display none -monitor stdio \
-drive file=a.qcow2,if=none,id=drv0 \
-blockdev file,filename=b.qcow2,node-name=bfile \
-blockdev qcow2,file=bfile,node-name=b0
(qemu) savevm s1
(qemu) info snapshots
(qemu) quit
qemu-img snapshot -l a.qcow2
qemu-img snapshot -l b.qcow2
Without the fix, only a.qcow2 has snapshot s1 and savevm does not
report an error. Since "info snapshots" uses the same iterator, it
even lists s1 as present on all disks. With the fix, both images have
it.
For savevm, only nodes without any parent are affected, since
snapshots only consider nodes that are attached to a BlockBackend or
have no parent at all. Such detached nodes are rare and often
short-lived in practice I think, which would explain the lack of
reports. Still, the failure is silent, it is a regression since 9.0,
and the fix is a single line, so I think it is a good candidate for
stable.
Best regards,
Erik
