| Message ID | 20190722172616.28797-5-mreitz@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | [PULL,1/5] block/nvme: fix doorbell stride | expand |
diff --git a/block/io.c b/block/io.c index b89e155d21..06305c6ea6 100644 --- a/block/io.c +++ b/block/io.c @@ -217,13 +217,12 @@ static void coroutine_fn bdrv_drain_invoke_entry(void *opaque) bs->drv->bdrv_co_drain_end(bs); } - /* Set data->done before reading bs->wakeup. */ + /* Set data->done and decrement drained_end_counter before bdrv_wakeup() */ atomic_mb_set(&data->done, true); - bdrv_dec_in_flight(bs); - if (!data->begin) { atomic_dec(data->drained_end_counter); } + bdrv_dec_in_flight(bs); g_free(data); }
Decrementing drained_end_counter after bdrv_dec_in_flight() (which in turn invokes bdrv_wakeup() and thus aio_wait_kick()) is not very clever. We should decrement it beforehand, so that any waiting aio_poll() that is woken by bdrv_dec_in_flight() sees the decremented drained_end_counter. Because the time window between decrementing drained_end_counter and aio_wait_kick() is very small, I cannot supply a reliable regression test. However, running e.g. the /bdrv-drain/blockjob/iothread/drain_all test in test-bdrv-drain has a small chance of hanging without this patch (about 1/200 or so; it gets to nearly 100 % if you add e.g. an fputc(' ', stderr); after the bdrv_dec_in_flight()). Fixes: e037c09c78520cbdb6da7cfc6ad0256d5870b814 Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20190722133054.21781-2-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com> --- block/io.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)