backup_clean is only ever called as a handler via job_exit, which already acquires the job's context. 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. Signed-off-by: Stefan Reiter <s.rei...@proxmox.com> --- This is a fix for the issue discussed in this part of the thread: https://lists.gnu.org/archive/html/qemu-devel/2020-03/msg07639.html ...not the original problem (core dump) posted by Dietmar. I've still seen it occasionally hang during a backup abort. I'm trying to figure out why that happens, stack trace indicates a similar problem with the main thread hanging at bdrv_do_drained_begin, though I have no clue why as of yet. block/backup.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/block/backup.c b/block/backup.c index 7430ca5883..a7a7dcaf4c 100644 --- a/block/backup.c +++ b/block/backup.c @@ -126,11 +126,7 @@ static void backup_abort(Job *job) static void backup_clean(Job *job) { BackupBlockJob *s = container_of(job, BackupBlockJob, common.job); - AioContext *aio_context = bdrv_get_aio_context(s->backup_top); - - aio_context_acquire(aio_context); bdrv_backup_top_drop(s->backup_top); - aio_context_release(aio_context); } void backup_do_checkpoint(BlockJob *job, Error **errp) -- 2.25.2
