Re: bdrv_drained_begin deadlock with io-threads

[Kevin Wolf]

Am 03.04.2020 um 18:31 hat Dietmar Maurer geschrieben:
> 
> > On April 3, 2020 10:47 AM Kevin Wolf <address@hidden> 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