diff options
author | Vladimir Sementsov-Ogievskiy | 2020-11-06 13:42:41 +0100 |
---|---|---|
committer | Max Reitz | 2020-12-18 12:35:55 +0100 |
commit | 071b474f5457c166f90a2c379508dc92b92dc1ae (patch) | |
tree | 10593fed9965dfff2cf4e6b5b979276a81083040 /block | |
parent | block: bdrv_child_set_perm() drop redundant parameters. (diff) | |
download | qemu-071b474f5457c166f90a2c379508dc92b92dc1ae.tar.gz qemu-071b474f5457c166f90a2c379508dc92b92dc1ae.tar.xz qemu-071b474f5457c166f90a2c379508dc92b92dc1ae.zip |
block: drop tighten_restrictions
The only users of this thing are:
1. bdrv_child_try_set_perm, to ignore failures on loosen restrictions
2. assertion in bdrv_replace_child
3. assertion in bdrv_inactivate_recurse
Assertions are not enough reason for overcomplication the permission
update system. So, look at bdrv_child_try_set_perm.
We are interested in tighten_restrictions only on failure. But on
failure this field is not reliable: we may fail in the middle of
permission update, some nodes are not touched and we don't know should
their permissions be tighten or not. So, we rely on the fact that if we
loose restrictions on some node (or BdrvChild), we'll not tighten
restriction in the whole subtree as part of this update (assertions 2
and 3 rely on this fact as well). And, if we rely on this fact anyway,
we can just check it on top, and don't pass additional pointer through
the whole recursive infrastructure.
Note also, that further patches will fix real bugs in permission update
system, so now is good time to simplify it, as a help for further
refactorings.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20201106124241.16950-8-vsementsov@virtuozzo.com>
[mreitz: Fixed rebase conflict]
Signed-off-by: Max Reitz <mreitz@redhat.com>
Diffstat (limited to 'block')
0 files changed, 0 insertions, 0 deletions