On Tue, Feb 04, 2025 at 10:14:02PM +0100, Kevin Wolf wrote:
> So far the assumption has always been that if we try to inactivate a
> node, it is already idle. This doesn't hold true any more if we allow
> inactivating exported nodes because we can't know when new external

'deactivating' sounds nicer than 'inactivating', but I can also see
why you went with 'inactivating' since the flag is centered around the
notion of INACTIVE.

> requests come in.
> 
> Drain the node around setting BDRV_O_INACTIVE so that requests can't
> start operating on an active node and then in the middle it suddenly
> becomes inactive. With this change, it's enough for exports to check
> for new requests that they operate on an active node (or, like reads,
> are allowed even on an inactive node).
> 
> Signed-off-by: Kevin Wolf <kw...@redhat.com>
> ---
>  block.c | 2 ++
>  1 file changed, 2 insertions(+)

Reviewed-by: Eric Blake <ebl...@redhat.com>

> 
> diff --git a/block.c b/block.c
> index 7eeb8d076e..1601b25f66 100644
> --- a/block.c
> +++ b/block.c
> @@ -7032,7 +7032,9 @@ bdrv_inactivate_recurse(BlockDriverState *bs, bool 
> top_level)
>          return -EPERM;
>      }
>  
> +    bdrv_drained_begin(bs);
>      bs->open_flags |= BDRV_O_INACTIVE;
> +    bdrv_drained_end(bs);
>  
>      /*
>       * Update permissions, they may differ for inactive nodes.
> -- 
> 2.48.1
> 
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org


Reply via email to