Skip to content
Snippets Groups Projects
  • Vladimir Sementsov-Ogievskiy's avatar
    071b474f
    block: drop tighten_restrictions · 071b474f
    Vladimir Sementsov-Ogievskiy authored
    
    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: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
    Message-Id: <20201106124241.16950-8-vsementsov@virtuozzo.com>
    [mreitz: Fixed rebase conflict]
    Signed-off-by: default avatarMax Reitz <mreitz@redhat.com>
    071b474f
    History
    block: drop tighten_restrictions
    Vladimir Sementsov-Ogievskiy authored
    
    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: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
    Message-Id: <20201106124241.16950-8-vsementsov@virtuozzo.com>
    [mreitz: Fixed rebase conflict]
    Signed-off-by: default avatarMax Reitz <mreitz@redhat.com>