Skip to content
Snippets Groups Projects
  • Kevin Wolf's avatar
    edcce17b
    preallocate: Don't poll during permission updates · edcce17b
    Kevin Wolf authored
    
    When the permission related BlockDriver callbacks are called, we are in
    the middle of an operation traversing the block graph. Polling in such a
    place is a very bad idea because the graph could change in unexpected
    ways. In the future, callers will also hold the graph lock, which is
    likely to turn polling into a deadlock.
    
    So we need to get rid of calls to functions like bdrv_getlength() or
    bdrv_truncate() there as these functions poll internally. They are
    currently used so that when no parent has write/resize permissions on
    the image any more, the preallocate filter drops the extra preallocated
    area in the image file and gives up write/resize permissions itself.
    
    In order to achieve this without polling in .bdrv_check_perm, don't
    immediately truncate the image, but only schedule a BH to do so. The
    filter keeps the write/resize permissions a bit longer now until the BH
    has executed.
    
    There is one case in which delaying doesn't work: Reopening the image
    read-only. In this case, bs->file will likely be reopened read-only,
    too, so keeping write permissions a bit longer on it doesn't work. But
    we can already cover this case in preallocate_reopen_prepare() and not
    rely on the permission updates for it.
    
    Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
    Reviewed-by: default avatarEric Blake <eblake@redhat.com>
    Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
    Message-ID: <20230911094620.45040-4-kwolf@redhat.com>
    Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
    edcce17b
    History
    preallocate: Don't poll during permission updates
    Kevin Wolf authored
    
    When the permission related BlockDriver callbacks are called, we are in
    the middle of an operation traversing the block graph. Polling in such a
    place is a very bad idea because the graph could change in unexpected
    ways. In the future, callers will also hold the graph lock, which is
    likely to turn polling into a deadlock.
    
    So we need to get rid of calls to functions like bdrv_getlength() or
    bdrv_truncate() there as these functions poll internally. They are
    currently used so that when no parent has write/resize permissions on
    the image any more, the preallocate filter drops the extra preallocated
    area in the image file and gives up write/resize permissions itself.
    
    In order to achieve this without polling in .bdrv_check_perm, don't
    immediately truncate the image, but only schedule a BH to do so. The
    filter keeps the write/resize permissions a bit longer now until the BH
    has executed.
    
    There is one case in which delaying doesn't work: Reopening the image
    read-only. In this case, bs->file will likely be reopened read-only,
    too, so keeping write permissions a bit longer on it doesn't work. But
    we can already cover this case in preallocate_reopen_prepare() and not
    rely on the permission updates for it.
    
    Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
    Reviewed-by: default avatarEric Blake <eblake@redhat.com>
    Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
    Message-ID: <20230911094620.45040-4-kwolf@redhat.com>
    Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>