From fa8fc1d09f9b4deaf764420ac11d8b3c88f8af60 Mon Sep 17 00:00:00 2001 From: Emanuele Giuseppe Esposito Date: Wed, 15 Dec 2021 07:11:38 -0500 Subject: block_int: make bdrv_backing_overridden static bdrv_backing_overridden is only used in block.c, so there is no need to leave it in block_int.h Signed-off-by: Emanuele Giuseppe Esposito Reviewed-by: Stefan Hajnoczi Message-Id: <20211215121140.456939-2-eesposit@redhat.com> Signed-off-by: Kevin Wolf --- include/block/block_int.h | 3 --- 1 file changed, 3 deletions(-) (limited to 'include/block') diff --git a/include/block/block_int.h b/include/block/block_int.h index f4c75e8ba9..27008cfb22 100644 --- a/include/block/block_int.h +++ b/include/block/block_int.h @@ -1122,9 +1122,6 @@ BlockDriver *bdrv_probe_all(const uint8_t *buf, int buf_size, void bdrv_parse_filename_strip_prefix(const char *filename, const char *prefix, QDict *options); -bool bdrv_backing_overridden(BlockDriverState *bs); - - /** * bdrv_add_aio_context_notifier: * -- cgit v1.2.3 From 64631f368115a332bdca32553a430568ecc7761d Mon Sep 17 00:00:00 2001 From: Vladimir Sementsov-Ogievskiy Date: Thu, 2 Sep 2021 12:37:54 +0300 Subject: block: drop BLK_PERM_GRAPH_MOD First, this permission never protected a node from being changed, as generic child-replacing functions don't check it. Second, it's a strange thing: it presents a permission of parent node to change its child. But generally, children are replaced by different mechanisms, like jobs or qmp commands, not by nodes. Graph-mod permission is hard to understand. All other permissions describe operations which done by parent node on its child: read, write, resize. Graph modification operations are something completely different. The only place where BLK_PERM_GRAPH_MOD is used as "perm" (not shared perm) is mirror_start_job, for s->target. Still modern code should use bdrv_freeze_backing_chain() to protect from graph modification, if we don't do it somewhere it may be considered as a bug. So, it's a bit risky to drop GRAPH_MOD, and analyzing of possible loss of protection is hard. But one day we should do it, let's do it now. One more bit of information is that locking the corresponding byte in file-posix doesn't make sense at all. Signed-off-by: Vladimir Sementsov-Ogievskiy Message-Id: <20210902093754.2352-1-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf --- include/block/block.h | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'include/block') diff --git a/include/block/block.h b/include/block/block.h index e5dd22b034..9d4050220b 100644 --- a/include/block/block.h +++ b/include/block/block.h @@ -269,12 +269,13 @@ enum { BLK_PERM_RESIZE = 0x08, /** - * This permission is required to change the node that this BdrvChild - * points to. + * There was a now-removed bit BLK_PERM_GRAPH_MOD, with value of 0x10. QEMU + * 6.1 and earlier may still lock the corresponding byte in block/file-posix + * locking. So, implementing some new permission should be very careful to + * not interfere with this old unused thing. */ - BLK_PERM_GRAPH_MOD = 0x10, - BLK_PERM_ALL = 0x1f, + BLK_PERM_ALL = 0x0f, DEFAULT_PERM_PASSTHROUGH = BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE -- cgit v1.2.3