Re: [PATCH v2 0/3] block: reject persistent bitmaps a node can never store

On 13.08.26 22:03, Denis V. Lunev wrote:
> On 7/29/26 21:17, Vladimir Sementsov-Ogievskiy wrote:
>> On 27.07.26 15:05, Denis V. Lunev wrote:
>>> On 7/16/26 13:22, Denis V. Lunev wrote:
>>>> This email originated from an IP that might not be authorized by the domain it was sent from.
>>>> Do not click links or open attachments unless it is an email you expected to receive.
>>>> qmp_block_dirty_bitmap_add() and the incoming-migration bitmap loader
>>>> both create a persistent bitmap with bdrv_create_dirty_bitmap(), which
>>>> always creates it writable, without checking whether the node can
>>>> actually be written to. A persistent bitmap added to an already
>>>> read-only or inactive node stays writable in memory on a node that
>>>> can never store it, and the next global inactivation (migration
>>>> completion, save, or any other bdrv_inactivate_all() caller) fails
>>>> trying to flush it back:
>>>>
>>>>     Lost persistent bitmaps during inactivation of node '<node>': No write access
>>>>     migration_block_inactivate: bdrv_inactivate_all() failed: -22
>>>>
>>>> Patch 1 rejects this at block-dirty-bitmap-add (and, wrapped in a
>>>> transaction, denies the whole transaction). Patch 2 closes the same
>>>> hole on the incoming-migration path. Patch 3 fixes a knock-on
>>>> regression from patch 1's approach: a bitmap that was rejected from
>>>> ever being written can still exist in memory read-only and must
>>>> remain removable without requiring write access.
>>>>
>>>> v1 -> v2
>>>> * approach changed to deny rather than adopt (Vladimir)
>>>> * added patch to add permission check on migration path
>>>> * added patch to change permissions check on bitmap drop to more natural
>>>>
>>>> Signed-off-by: Denis V. Lunev <[email protected]>
>>>> CC: Eric Blake <[email protected]>
>>>> CC: Vladimir Sementsov-Ogievskiy <[email protected]>
>>>> CC: John Snow <[email protected]>
>>>> CC: Andrey Drobyshev <[email protected]>
>>>>
>>>> Denis V. Lunev (3):
>>>>     block/monitor: reject persistent bitmap add on a read-only node
>>>>     migration/block-dirty-bitmap: reject bitmap load onto ro node
>>>>     block/monitor: allow dropping a bitmap never stored on disk
>>>>
>>>>    block/monitor/bitmap-qmp-cmds.c               | 19 +++++++----
>>>>    block/qcow2-bitmap.c                          |  9 +++++
>>>>    migration/block-dirty-bitmap.c                | 22 +++++++++----
>>>>    qapi/block-core.json                          |  4 ++-
>>>>    tests/qemu-iotests/tests/migrate-bitmaps-test | 33 +++++++++++++++++++
>>>>    .../tests/migrate-bitmaps-test.out            |  4 +--
>>>>    .../tests/remove-bitmap-from-backing          | 29 +++++++++++++++-
>>>>    .../tests/remove-bitmap-from-backing.out      | 22 ++++++++++++-
>>>>    8 files changed, 124 insertions(+), 18 deletions(-)
>>>>
>>> Hi, Vladimir!
>>>
>>> Will this go through your tree? It is looking like nobody else cares.
>>>
>> Yes, seems so. Thanks, applied to my block branch.
>>
>> There's still a chance to stop me within 2-3 weeks before 11.2 cycle opens.
>>
> Hmmm :-)
> 
> 11.2 seems opened. Is it right time to push?
> 
Was on vacation :). Will do this week.

-- 
Best regards,
Vladimir