On Thu, 21 Nov 2019 12:04:58 -0600
Eric Blake <ebl...@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 <lukasstra...@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
> >
> >
>
