qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] hw/virtio/vhost-user: avoid using unitialized errp


From: Peter Maydell
Subject: Re: [PATCH] hw/virtio/vhost-user: avoid using unitialized errp
Date: Mon, 6 Mar 2023 16:01:29 +0000

On Thu, 2 Mar 2023 at 12:18, Albert Esteve <aesteve@redhat.com> wrote:
>
> During protocol negotiation, when we the QEMU
> stub does not support a backend with F_CONFIG,
> it throws a warning and supresses the
> VHOST_USER_PROTOCOL_F_CONFIG bit.
>
> However, the warning uses warn_reportf_err macro
> and passes an unitialized errp pointer. However,
> the macro tries to edit the 'msg' member of the
> unitialized Error and segfaults.
>
> Instead, just use warn_report, which prints a
> warning message directly to the output.
>
> Fixes: 5653493 ("hw/virtio/vhost-user: don't suppress F_CONFIG when 
> supported")
> Signed-off-by: Albert Esteve <aesteve@redhat.com>
> ---
>  hw/virtio/vhost-user.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/hw/virtio/vhost-user.c b/hw/virtio/vhost-user.c
> index e68daa35d4..34c331b3ba 100644
> --- a/hw/virtio/vhost-user.c
> +++ b/hw/virtio/vhost-user.c
> @@ -2031,8 +2031,8 @@ static int vhost_user_backend_init(struct vhost_dev 
> *dev, void *opaque,
>          } else {
>              if (virtio_has_feature(protocol_features,
>                                     VHOST_USER_PROTOCOL_F_CONFIG)) {
> -                warn_reportf_err(*errp, "vhost-user backend supports "
> -                                 "VHOST_USER_PROTOCOL_F_CONFIG but QEMU does 
> not.");
> +                warn_report("vhost-user backend supports "
> +                            "VHOST_USER_PROTOCOL_F_CONFIG but QEMU does 
> not.");
>                  protocol_features &= ~(1ULL << VHOST_USER_PROTOCOL_F_CONFIG);
>              }
>          }

This looks like the right fix to me. warn_reportf_err() is for
"print this message along with the information in the Error object".
But in this code path we are not trying to handle an error that
was reported to us by a function that sets up Error, so it's
not the right function to use.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]