[libvirt] [PATCH] storage: Remove redundant refreshPool check

John Ferlan jferlan at redhat.com
Thu Jun 23 19:53:51 UTC 2016



On 06/22/2016 08:29 PM, Cole Robinson wrote:
> Every driver provides a refreshPool impl, and many other critical
> places in the code unconditionally call it without checking if
> it exists, so this check is pointless
> ---
>  src/storage/storage_driver.c | 16 +++++++---------
>  1 file changed, 7 insertions(+), 9 deletions(-)
> 
> diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c
> index e2d729f..4b5419d 100644
> --- a/src/storage/storage_driver.c
> +++ b/src/storage/storage_driver.c
> @@ -2422,20 +2422,18 @@ storageVolUpload(virStorageVolPtr obj,
>          goto cleanup;
>      }
>  
> -    /* If we have a refreshPool, use the callback routine in order to
> +    /* Use the callback routine in order to
>       * refresh the pool after the volume upload stream closes. This way
>       * we make sure the volume and pool data are refreshed without user
>       * interaction and we can just lookup the backend in the callback
>       * routine in order to call the refresh API.
>       */
> -    if (backend->refreshPool) {
> -        if (VIR_ALLOC(cbdata) < 0 ||
> -            VIR_STRDUP(cbdata->pool_name, pool->def->name) < 0)
> -            goto cleanup;
> -        if (vol->target.type == VIR_STORAGE_VOL_PLOOP &&
> -            VIR_STRDUP(cbdata->vol_path, vol->target.path) < 0)
> -            goto cleanup;
> -    }
> +    if (VIR_ALLOC(cbdata) < 0 ||
> +        VIR_STRDUP(cbdata->pool_name, pool->def->name) < 0)
> +        goto cleanup;
> +    if (vol->target.type == VIR_STORAGE_VOL_PLOOP &&
> +        VIR_STRDUP(cbdata->vol_path, vol->target.path) < 0)
> +        goto cleanup;
>  
>      if ((ret = backend->uploadVol(obj->conn, pool, vol, stream,
>                                    offset, length, flags)) < 0)
> 
Of course my Coverity checker just pointed out that the subsequent "if
(cbdata)" below here is not necessary now since cbdata will always be
allocated <sigh>.


John




More information about the libvir-list mailing list