Re: [PATCH] block: fix bdrv_next() skipping monitor-owned nodes

["Denis V. Lunev" <den@virtuozzo.com>]

On 9/1/26 14:23, Fiona Ebner wrote:
> Hi Denis,
>
> Am 29.08.26 um 12:20 AM schrieb Denis V. Lunev:
>> From: Denis V. Lunev <den@openvz.org>
>>
>> it->bs is the cursor into monitor_bdrv_states for the second phase of
>> bdrv_next(), so it has to be NULL when that phase starts. Commit
>> f6d38c9f6d made the first phase store the node it returns there, to
>> unreference the right one when the graph changes underneath. The cursor
>> is now left pointing at the last BlockBackend root, so the second phase
>> resumes from there instead of from the head of the list and never
>> returns a node added before it.
>>
>> A skipped node drops out of the vm_stop and migration handover paths:
>> not flushed, not inactivated, not snapshotted. bdrv_inactivate_all()
>> still reports success, so the node keeps its image lock and the
>> migration target cannot open the image. Only detached nodes are hit in
>> practice, as these callers also recurse into children.
>>
>> Reset the cursor when the second phase starts. old_bs is taken at the
>> top of the function, so f6d38c9f6d keeps working.
>>
>> Fixes: f6d38c9f6d ("block-backend: fix edge case in bdrv_next() where BDS associated to BB changes")
>> Signed-off-by: Denis V. Lunev <den@openvz.org>
>> Cc: Fiona Ebner <f.ebner@proxmox.com>
>> Cc: Kevin Wolf <kwolf@redhat.com>
> thank you for the fix!
>
> Reviewed-by: Fiona Ebner <f.ebner@proxmox.com>
> Tested-by: Fiona Ebner <f.ebner@proxmox.com>
>
> 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.

Den