From: Zhao Liu <zhao1.liu@intel.com>

As the comment in qapi/error, passing @errp to error_prepend() requires
ERRP_GUARD():

* = Why, when and how to use ERRP_GUARD() =
*
* Without ERRP_GUARD(), use of the @errp parameter is restricted:
...
* - It should not be passed to error_prepend(), error_vprepend() or
*   error_append_hint(), because that doesn't work with &error_fatal.
* ERRP_GUARD() lifts these restrictions.
*
* To use ERRP_GUARD(), add it right at the beginning of the function.
* @errp can then be used without worrying about the argument being
* NULL or &error_fatal.

ERRP_GUARD() could avoid the case when @errp is the pointer of
error_fatal, the user can't see this additional information, because
exit() happens in error_setg earlier than information is added [1].

The set_chr() passes @errp to error_prepend() without ERRP_GUARD().

As a PropertyInfo.set method, the @errp passed to set_chr() is so widely
sourced that it is necessary to protect it with ERRP_GUARD().

To avoid the issue like [1] said, add missing ERRP_GUARD() at the
beginning of this function.

[1]: Issue description in the commit message of commit ae7c80a7bd73
     ("error: New macro ERRP_GUARD()").

Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Eduardo Habkost <eduardo@habkost.net>
Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
---
 hw/core/qdev-properties-system.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-properties-system.c
index 1a396521d51f..545c3ceff7c9 100644
--- a/hw/core/qdev-properties-system.c
+++ b/hw/core/qdev-properties-system.c
@@ -242,6 +242,7 @@ static void get_chr(Object *obj, Visitor *v, const char *name, void *opaque,
 static void set_chr(Object *obj, Visitor *v, const char *name, void *opaque,
                     Error **errp)
 {
+    ERRP_GUARD();
     Property *prop = opaque;
     CharBackend *be = object_field_prop_ptr(obj, prop);
     Chardev *s;
-- 
2.34.1

Zhao Liu <zhao1.liu@linux.intel.com> writes:

> From: Zhao Liu <zhao1.liu@intel.com>
>
> As the comment in qapi/error, passing @errp to error_prepend() requires
> ERRP_GUARD():
>
> * = Why, when and how to use ERRP_GUARD() =
> *
> * Without ERRP_GUARD(), use of the @errp parameter is restricted:
> ...
> * - It should not be passed to error_prepend(), error_vprepend() or
> *   error_append_hint(), because that doesn't work with &error_fatal.
> * ERRP_GUARD() lifts these restrictions.
> *
> * To use ERRP_GUARD(), add it right at the beginning of the function.
> * @errp can then be used without worrying about the argument being
> * NULL or &error_fatal.
>
> ERRP_GUARD() could avoid the case when @errp is the pointer of
> error_fatal, the user can't see this additional information, because

Suggest "when @errp is &error_fatal"

> exit() happens in error_setg earlier than information is added [1].
>
> The set_chr() passes @errp to error_prepend() without ERRP_GUARD().
>
> As a PropertyInfo.set method, the @errp passed to set_chr() is so widely
> sourced that it is necessary to protect it with ERRP_GUARD().

"sourced"?  Do you mean "used"?

Are you trying to say something like "there are too many possible
callers for me to check the impact of this defect; it may or may not be
harmless."

> To avoid the issue like [1] said, add missing ERRP_GUARD() at the
> beginning of this function.
>
> [1]: Issue description in the commit message of commit ae7c80a7bd73
>      ("error: New macro ERRP_GUARD()").
>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: "Daniel P. Berrangé" <berrange@redhat.com>
> Cc: Eduardo Habkost <eduardo@habkost.net>
> Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
> ---
>  hw/core/qdev-properties-system.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-properties-system.c
> index 1a396521d51f..545c3ceff7c9 100644
> --- a/hw/core/qdev-properties-system.c
> +++ b/hw/core/qdev-properties-system.c
> @@ -242,6 +242,7 @@ static void get_chr(Object *obj, Visitor *v, const char *name, void *opaque,
>  static void set_chr(Object *obj, Visitor *v, const char *name, void *opaque,
>                      Error **errp)
>  {
> +    ERRP_GUARD();
>      Property *prop = opaque;
>      CharBackend *be = object_field_prop_ptr(obj, prop);
>      Chardev *s;

Commit message could use a bit of polish.  Regardless
Reviewed-by: Markus Armbruster <armbru@redhat.com>

Hi Markus,

> > ERRP_GUARD() could avoid the case when @errp is the pointer of
> > error_fatal, the user can't see this additional information, because
> 
> Suggest "when @errp is &error_fatal"

Sure! It's clearer.

> > exit() happens in error_setg earlier than information is added [1].
> >
> > The set_chr() passes @errp to error_prepend() without ERRP_GUARD().
> >
> > As a PropertyInfo.set method, the @errp passed to set_chr() is so widely
> > sourced that it is necessary to protect it with ERRP_GUARD().
> 
> "sourced"?  Do you mean "used"?
> 
> Are you trying to say something like "there are too many possible
> callers for me to check the impact of this defect; it may or may not be
> harmless."

Yes! Very well expressed. Thanks for your words.

> > To avoid the issue like [1] said, add missing ERRP_GUARD() at the
> > beginning of this function.
> >

[snip]

> Commit message could use a bit of polish.  Regardless
> Reviewed-by: Markus Armbruster <armbru@redhat.com>
> 

Thanks!

-Zhao

Zhao Liu <zhao1.liu@linux.intel.com> writes:

> Hi Markus,
>
>> > ERRP_GUARD() could avoid the case when @errp is the pointer of
>> > error_fatal, the user can't see this additional information, because
>> 
>> Suggest "when @errp is &error_fatal"
>
> Sure! It's clearer.
>
>> > exit() happens in error_setg earlier than information is added [1].
>> >
>> > The set_chr() passes @errp to error_prepend() without ERRP_GUARD().
>> >
>> > As a PropertyInfo.set method, the @errp passed to set_chr() is so widely
>> > sourced that it is necessary to protect it with ERRP_GUARD().
>> 
>> "sourced"?  Do you mean "used"?
>> 
>> Are you trying to say something like "there are too many possible
>> callers for me to check the impact of this defect; it may or may not be
>> harmless."
>
> Yes! Very well expressed. Thanks for your words.

You're welcome!  Go ahead and replace your sentence with it.

>> > To avoid the issue like [1] said, add missing ERRP_GUARD() at the
>> > beginning of this function.
>> >
>
> [snip]
>
>> Commit message could use a bit of polish.  Regardless
>> Reviewed-by: Markus Armbruster <armbru@redhat.com>
>> 
>
> Thanks!
>
> -Zhao