Re: [PATCH 1/4] block/quorum.c: stable children names

[Eric Blake <eblake@redhat.com>]

On 11/21/19 11:49 AM, Lukas Straub wrote:
> If we remove the child with the highest index from the quorum,
> decrement s->next_child_index. This way we get stable children
> names as long as we only remove the last child.
> 
> Signed-off-by: Lukas Straub <lukasstraub2@web.de>
> ---
>   block/quorum.c | 6 ++++++
>   1 file changed, 6 insertions(+)
> 
> diff --git a/block/quorum.c b/block/quorum.c
> index df68adcfaa..6100d4108a 100644
> --- a/block/quorum.c
> +++ b/block/quorum.c
> @@ -1054,6 +1054,12 @@ static void quorum_del_child(BlockDriverState *bs, BdrvChild *child,
>       /* We know now that num_children > threshold, so blkverify must be false */
>       assert(!s->is_blkverify);
> 
> +    unsigned child_id;
> +    sscanf(child->name, "children.%u", &child_id);

sscanf() cannot detect overflow. Do we trust our input enough to ignore 
this shortfall in the interface, or should we be using saner interfaces 
like qemu_strtoul()?  For that matter, why do we have to reparse 
something; is it not already available somewhere in numerical form?

> +    if (child_id == s->next_child_index - 1) {
> +        s->next_child_index--;
> +    }
> +
>       bdrv_drained_begin(bs);
> 
>       /* We can safely remove this child now */
> --
> 2.20.1
> 
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org