Am 03.04.2020 um 18:31 hat Dietmar Maurer geschrieben: > > > On April 3, 2020 10:47 AM Kevin Wolf <kw...@redhat.com> wrote: > > > > > > Am 03.04.2020 um 10:26 hat Dietmar Maurer geschrieben: > > > > With the following patch, it seems to survive for now. I'll give it some > > > > more testing tomorrow (also qemu-iotests to check that I didn't > > > > accidentally break something else.) > > > > > > Wow, that was fast! Seems your patch fixes the bug! > > > > > > I wonder what commit introduced that problem, maybe: > > > > > > https://github.com/qemu/qemu/commit/cf3129323f900ef5ddbccbe86e4fa801e88c566e#diff-7cb66df56045598b75a219eebc27efb6 > > > > > > If so, version 4.1.X in not affected by this bug, but 4.2.0 and later? > > > > Yes, I'm pretty sure that's the one. > > I also wonder if we can loose an aio_wait_kick() by directly accessing > blk->in_flight. > I thought this should use atomic_mb_read()? > > diff --git a/block/block-backend.c b/block/block-backend.c > index 8b8f2a80a0..48f3721505 100644 > --- a/block/block-backend.c > +++ b/block/block-backend.c > @@ -2275,7 +2275,7 @@ static bool blk_root_drained_poll(BdrvChild *child) > { > BlockBackend *blk = child->opaque; > assert(blk->quiesce_counter); > - return !!blk->in_flight; > + return !!atomic_mb_read(&blk->in_flight); > }
I'm not sure if it actually makes a difference (and especially what the barrier is supposed to achieve here), but it would be more consistent with other users of the variable, so I think I agree. Kevin