There is no need for the AioContext lock in bdrv_drain_all() because nothing in AIO_WAIT_WHILE() needs the lock and the condition is atomic.
Note that the NULL AioContext argument to AIO_WAIT_WHILE() is odd. In the future it can be removed. There is an assertion in AIO_WAIT_WHILE() that checks that we're in the main loop AioContext and we would lose that check by dropping the argument. However, that was a precursor to the GLOBAL_STATE_CODE()/IO_CODE() macros and is now a duplicate check. So I think we won't lose much by dropping it, but let's do a few more AIO_WAIT_WHILE_UNLOCKED() coversions of this sort to confirm this is the case. Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com> --- block/block-backend.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/block/block-backend.c b/block/block-backend.c index 278b04ce69..d2b6b3652d 100644 --- a/block/block-backend.c +++ b/block/block-backend.c @@ -1835,14 +1835,8 @@ void blk_drain_all(void) bdrv_drain_all_begin(); while ((blk = blk_all_next(blk)) != NULL) { - AioContext *ctx = blk_get_aio_context(blk); - - aio_context_acquire(ctx); - /* We may have -ENOMEDIUM completions in flight */ - AIO_WAIT_WHILE(ctx, qatomic_mb_read(&blk->in_flight) > 0); - - aio_context_release(ctx); + AIO_WAIT_WHILE_UNLOCKED(NULL, qatomic_mb_read(&blk->in_flight) > 0); } bdrv_drain_all_end(); -- 2.39.2