qapi/block-core.json | 7 ++----- include/block/block.h | 9 +++++---- block.c | 7 +------ block/commit.c | 1 - block/mirror.c | 15 +++------------ hw/block/block.c | 3 +-- scripts/render_block_graph.py | 1 - tests/qemu-iotests/273.out | 4 ---- 8 files changed, 12 insertions(+), 35 deletions(-)
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 <vsementsov@virtuozzo.com>
---
v2: fix grammar
qapi/block-core.json | 7 ++-----
include/block/block.h | 9 +++++----
block.c | 7 +------
block/commit.c | 1 -
block/mirror.c | 15 +++------------
hw/block/block.c | 3 +--
scripts/render_block_graph.py | 1 -
tests/qemu-iotests/273.out | 4 ----
8 files changed, 12 insertions(+), 35 deletions(-)
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 06674c25c9..6fa2c4ab82 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1825,14 +1825,11 @@
#
# @resize: This permission is required to change the size of a block node.
#
-# @graph-mod: This permission is required to change the node that this
-# BdrvChild points to.
-#
# Since: 4.0
##
{ 'enum': 'BlockPermission',
- 'data': [ 'consistent-read', 'write', 'write-unchanged', 'resize',
- 'graph-mod' ] }
+ 'data': [ 'consistent-read', 'write', 'write-unchanged', 'resize' ] }
+
##
# @XDbgBlockGraphEdge:
#
diff --git a/include/block/block.h b/include/block/block.h
index 3477290f9a..bccca61429 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
diff --git a/block.c b/block.c
index e97ce0b1c8..761d47d6f3 100644
--- a/block.c
+++ b/block.c
@@ -2397,7 +2397,6 @@ char *bdrv_perm_names(uint64_t perm)
{ BLK_PERM_WRITE, "write" },
{ BLK_PERM_WRITE_UNCHANGED, "write unchanged" },
{ BLK_PERM_RESIZE, "resize" },
- { BLK_PERM_GRAPH_MOD, "change children" },
{ 0, NULL }
};
@@ -2513,8 +2512,7 @@ static void bdrv_default_perms_for_cow(BlockDriverState *bs, BdrvChild *c,
shared = 0;
}
- shared |= BLK_PERM_CONSISTENT_READ | BLK_PERM_GRAPH_MOD |
- BLK_PERM_WRITE_UNCHANGED;
+ shared |= BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE_UNCHANGED;
if (bs->open_flags & BDRV_O_INACTIVE) {
shared |= BLK_PERM_WRITE | BLK_PERM_RESIZE;
@@ -2632,7 +2630,6 @@ uint64_t bdrv_qapi_perm_to_blk_perm(BlockPermission qapi_perm)
[BLOCK_PERMISSION_WRITE] = BLK_PERM_WRITE,
[BLOCK_PERMISSION_WRITE_UNCHANGED] = BLK_PERM_WRITE_UNCHANGED,
[BLOCK_PERMISSION_RESIZE] = BLK_PERM_RESIZE,
- [BLOCK_PERMISSION_GRAPH_MOD] = BLK_PERM_GRAPH_MOD,
};
QEMU_BUILD_BUG_ON(ARRAY_SIZE(permissions) != BLOCK_PERMISSION__MAX);
@@ -5326,8 +5323,6 @@ int bdrv_drop_intermediate(BlockDriverState *top, BlockDriverState *base,
update_inherits_from = bdrv_inherits_from_recursive(base, explicit_top);
/* success - we can delete the intermediate states, and link top->base */
- /* TODO Check graph modification op blockers (BLK_PERM_GRAPH_MOD) once
- * we've figured out how they should work. */
if (!backing_file_str) {
bdrv_refresh_filename(base);
backing_file_str = base->filename;
diff --git a/block/commit.c b/block/commit.c
index 42792b4556..837b07e314 100644
--- a/block/commit.c
+++ b/block/commit.c
@@ -370,7 +370,6 @@ void commit_start(const char *job_id, BlockDriverState *bs,
s->base = blk_new(s->common.job.aio_context,
base_perms,
BLK_PERM_CONSISTENT_READ
- | BLK_PERM_GRAPH_MOD
| BLK_PERM_WRITE_UNCHANGED);
ret = blk_insert_bs(s->base, base, errp);
if (ret < 0) {
diff --git a/block/mirror.c b/block/mirror.c
index 98fc66eabf..5ab0174446 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -1147,10 +1147,7 @@ static void mirror_complete(Job *job, Error **errp)
replace_aio_context = bdrv_get_aio_context(s->to_replace);
aio_context_acquire(replace_aio_context);
- /* TODO Translate this into permission system. Current definition of
- * GRAPH_MOD would require to request it for the parents; they might
- * not even be BlockDriverStates, however, so a BdrvChild can't address
- * them. May need redefinition of GRAPH_MOD. */
+ /* TODO Translate this into child freeze system. */
error_setg(&s->replace_blocker,
"block device is in use by block-job-complete");
bdrv_op_block_all(s->to_replace, s->replace_blocker);
@@ -1658,7 +1655,7 @@ static BlockJob *mirror_start_job(
s = block_job_create(job_id, driver, NULL, mirror_top_bs,
BLK_PERM_CONSISTENT_READ,
BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE_UNCHANGED |
- BLK_PERM_WRITE | BLK_PERM_GRAPH_MOD, speed,
+ BLK_PERM_WRITE, speed,
creation_flags, cb, opaque, errp);
if (!s) {
goto fail;
@@ -1702,9 +1699,7 @@ static BlockJob *mirror_start_job(
target_perms |= BLK_PERM_RESIZE;
}
- target_shared_perms |= BLK_PERM_CONSISTENT_READ
- | BLK_PERM_WRITE
- | BLK_PERM_GRAPH_MOD;
+ target_shared_perms |= BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE;
} else if (bdrv_chain_contains(bs, bdrv_skip_filters(target))) {
/*
* We may want to allow this in the future, but it would
@@ -1715,10 +1710,6 @@ static BlockJob *mirror_start_job(
goto fail;
}
- if (backing_mode != MIRROR_LEAVE_BACKING_CHAIN) {
- target_perms |= BLK_PERM_GRAPH_MOD;
- }
-
s->target = blk_new(s->common.job.aio_context,
target_perms, target_shared_perms);
ret = blk_insert_bs(s->target, target, errp);
diff --git a/hw/block/block.c b/hw/block/block.c
index d47ebf005a..25f45df723 100644
--- a/hw/block/block.c
+++ b/hw/block/block.c
@@ -171,8 +171,7 @@ bool blkconf_apply_backend_options(BlockConf *conf, bool readonly,
perm |= BLK_PERM_WRITE;
}
- shared_perm = BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE_UNCHANGED |
- BLK_PERM_GRAPH_MOD;
+ shared_perm = BLK_PERM_CONSISTENT_READ | BLK_PERM_WRITE_UNCHANGED;
if (resizable) {
shared_perm |= BLK_PERM_RESIZE;
}
diff --git a/scripts/render_block_graph.py b/scripts/render_block_graph.py
index da6acf050d..42288a3cfb 100755
--- a/scripts/render_block_graph.py
+++ b/scripts/render_block_graph.py
@@ -35,7 +35,6 @@ def perm(arr):
s = 'w' if 'write' in arr else '_'
s += 'r' if 'consistent-read' in arr else '_'
s += 'u' if 'write-unchanged' in arr else '_'
- s += 'g' if 'graph-mod' in arr else '_'
s += 's' if 'resize' in arr else '_'
return s
diff --git a/tests/qemu-iotests/273.out b/tests/qemu-iotests/273.out
index 4e840b6730..6a74a8138b 100644
--- a/tests/qemu-iotests/273.out
+++ b/tests/qemu-iotests/273.out
@@ -204,7 +204,6 @@ Testing: -blockdev file,node-name=base,filename=TEST_DIR/t.IMGFMT.base -blockdev
"name": "file",
"parent": 5,
"shared-perm": [
- "graph-mod",
"write-unchanged",
"consistent-read"
],
@@ -219,7 +218,6 @@ Testing: -blockdev file,node-name=base,filename=TEST_DIR/t.IMGFMT.base -blockdev
"name": "backing",
"parent": 5,
"shared-perm": [
- "graph-mod",
"resize",
"write-unchanged",
"write",
@@ -233,7 +231,6 @@ Testing: -blockdev file,node-name=base,filename=TEST_DIR/t.IMGFMT.base -blockdev
"name": "file",
"parent": 3,
"shared-perm": [
- "graph-mod",
"write-unchanged",
"consistent-read"
],
@@ -246,7 +243,6 @@ Testing: -blockdev file,node-name=base,filename=TEST_DIR/t.IMGFMT.base -blockdev
"name": "backing",
"parent": 3,
"shared-perm": [
- "graph-mod",
"resize",
"write-unchanged",
"write",
--
2.29.2
On Thu, Sep 02, 2021 at 12:37:54PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> 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 <vsementsov@virtuozzo.com>
> ---
>
> v2: fix grammar
>
> qapi/block-core.json | 7 ++-----
> include/block/block.h | 9 +++++----
> block.c | 7 +------
> block/commit.c | 1 -
> block/mirror.c | 15 +++------------
> hw/block/block.c | 3 +--
> scripts/render_block_graph.py | 1 -
> tests/qemu-iotests/273.out | 4 ----
> 8 files changed, 12 insertions(+), 35 deletions(-)
>
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 06674c25c9..6fa2c4ab82 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -1825,14 +1825,11 @@
> #
> # @resize: This permission is required to change the size of a block node.
> #
> -# @graph-mod: This permission is required to change the node that this
> -# BdrvChild points to.
> -#
Do we need to mention that graph-mod was removed in 6.2?
> # Since: 4.0
> ##
> { 'enum': 'BlockPermission',
> - 'data': [ 'consistent-read', 'write', 'write-unchanged', 'resize',
> - 'graph-mod' ] }
> + 'data': [ 'consistent-read', 'write', 'write-unchanged', 'resize' ] }
> +
> ##
> # @XDbgBlockGraphEdge:
> #
Otherwise the patch makes sense to me, but I'd rather that Kevin chime in.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Ping)
03.09.2021 21:47, Eric Blake wrote:
> On Thu, Sep 02, 2021 at 12:37:54PM +0300, Vladimir Sementsov-Ogievskiy wrote:
>> 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
[..]
>>
>> diff --git a/qapi/block-core.json b/qapi/block-core.json
>> index 06674c25c9..6fa2c4ab82 100644
>> --- a/qapi/block-core.json
>> +++ b/qapi/block-core.json
>> @@ -1825,14 +1825,11 @@
>> #
>> # @resize: This permission is required to change the size of a block node.
>> #
>> -# @graph-mod: This permission is required to change the node that this
>> -# BdrvChild points to.
>> -#
>
> Do we need to mention that graph-mod was removed in 6.2?
This structure is used only for debugging purposes, I don't think it worth mentioning.
>
>> # Since: 4.0
>> ##
>> { 'enum': 'BlockPermission',
>> - 'data': [ 'consistent-read', 'write', 'write-unchanged', 'resize',
>> - 'graph-mod' ] }
>> + 'data': [ 'consistent-read', 'write', 'write-unchanged', 'resize' ] }
>> +
>> ##
>> # @XDbgBlockGraphEdge:
>> #
>
> Otherwise the patch makes sense to me, but I'd rather that Kevin chime in.
>
--
Best regards,
Vladimir
Ping) Patch is reviewed. 02.09.2021 12:37, Vladimir Sementsov-Ogievskiy wrote: > 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<vsementsov@virtuozzo.com> -- Best regards, Vladimir
Am 02.09.2021 um 11:37 hat Vladimir Sementsov-Ogievskiy geschrieben: > 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 <vsementsov@virtuozzo.com> Thanks, applied to the block branch. Kevin
© 2016 - 2024 Red Hat, Inc.