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

[Lukas Straub <lukasstraub2@web.de>]

On Thu, 21 Nov 2019 12:04:58 -0600
Eric Blake <eblake@redhat.com> wrote:

> 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?

Hi,
Yes, I wondered about that too, but found no other way. But the input
is trusted, AFAIK the only way to add child nodes is trough quorum_add_child
above and quorum_open and there already are adequate checks there.

> > +    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
> >
> >
>