Skip to content
  • Stefan Reiter's avatar
    eca0f352
    backup: don't acquire aio_context in backup_clean · eca0f352
    Stefan Reiter authored
    
    
    All code-paths leading to backup_clean (via job_clean) have the job's
    context already acquired. The job's context is guaranteed to be the same
    as the one used by backup_top via backup_job_create.
    
    Since the previous logic effectively acquired the lock twice, this
    broke cleanup of backups for disks using IO threads, since the BDRV_POLL_WHILE
    in bdrv_backup_top_drop -> bdrv_do_drained_begin would only release the lock
    once, thus deadlocking with the IO thread.
    
    This is a partial revert of 0abf2581.
    
    Signed-off-by: default avatarStefan Reiter <s.reiter@proxmox.com>
    Reviewed-by: default avatarMax Reitz <mreitz@redhat.com>
    Message-Id: <20200407115651.69472-4-s.reiter@proxmox.com>
    Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
    eca0f352
    backup: don't acquire aio_context in backup_clean
    Stefan Reiter authored
    
    
    All code-paths leading to backup_clean (via job_clean) have the job's
    context already acquired. The job's context is guaranteed to be the same
    as the one used by backup_top via backup_job_create.
    
    Since the previous logic effectively acquired the lock twice, this
    broke cleanup of backups for disks using IO threads, since the BDRV_POLL_WHILE
    in bdrv_backup_top_drop -> bdrv_do_drained_begin would only release the lock
    once, thus deadlocking with the IO thread.
    
    This is a partial revert of 0abf2581.
    
    Signed-off-by: default avatarStefan Reiter <s.reiter@proxmox.com>
    Reviewed-by: default avatarMax Reitz <mreitz@redhat.com>
    Message-Id: <20200407115651.69472-4-s.reiter@proxmox.com>
    Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
Loading