aboutsummaryrefslogtreecommitdiff
path: root/COPYING.LIB
diff options
context:
space:
mode:
authorVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>2021-09-02 12:37:54 +0300
committerKevin Wolf <kwolf@redhat.com>2022-01-14 12:03:16 +0100
commit64631f368115a332bdca32553a430568ecc7761d (patch)
treef021ad8fa5dae349eafd7a234407fd06e0a7816c /COPYING.LIB
parent96054c76ff2db74165385a69f234c57a6bbc941e (diff)
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 <vsementsov@virtuozzo.com> Message-Id: <20210902093754.2352-1-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'COPYING.LIB')
0 files changed, 0 insertions, 0 deletions