[libvirt] [PATCHv2 2/2] virNetDevBandwidthEqual: Make it more robust

Laine Stump laine at laine.org
Wed Oct 2 08:44:52 UTC 2013


On 10/02/2013 03:34 AM, Michal Privoznik wrote:
> So far the virNetDevBandwidthEqual() expected both ->in and ->out items
> to be allocated for both @a and @b compared. This is not necessary true
> for all our code. For instance, running 'update-device' twice over a NIC
> with the very same XML results in SIGSEGV-ing in this function.
>
> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> ---
>  src/util/virnetdevbandwidth.c | 26 ++++++++++++++++++++------
>  1 file changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/src/util/virnetdevbandwidth.c b/src/util/virnetdevbandwidth.c
> index 42b0a50..17f4fa3 100644
> --- a/src/util/virnetdevbandwidth.c
> +++ b/src/util/virnetdevbandwidth.c
> @@ -335,16 +335,30 @@ virNetDevBandwidthEqual(virNetDevBandwidthPtr a,
>          return false;
>  
>      /* in */
> -    if (a->in->average != b->in->average ||
> -        a->in->peak != b->in->peak ||
> -        a->in->burst != b->in->burst)
> +    if (a->in) {
> +        if (!b->in)
> +            return false;
> +
> +        if (a->in->average != b->in->average ||
> +            a->in->peak != b->in->peak ||
> +            a->in->burst != b->in->burst)
> +            return false;
> +    } else if (b->in) {
>          return false;
> +    }
>  
>      /*out*/
> -    if (a->out->average != b->out->average ||
> -        a->out->peak != b->out->peak ||
> -        a->out->burst != b->out->burst)
> +    if (a->out) {
> +        if (!b->out)
> +            return false;
> +
> +        if (a->out->average != b->out->average ||
> +            a->out->peak != b->out->peak ||
> +            a->out->burst != b->out->burst)
> +            return false;
> +    } else if (b->out) {
>          return false;
> +    }
>  
>      return true;
>  }

ACK. Could this lead to a segv prior to applying the previous patch? Or
does it only become a problem once you support bandwidth change in
qemuChangeNet?

In either case, I think this patch should be pushed upstream *before*
patch 1/2, so that we don't create a window in the history where a new
segv is introduced (just in case someone is doing a bisect and hits on
that particular revision).




More information about the libvir-list mailing list