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? Thank you in advance, Den
