[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH-for-5.1] hw/nvram/fw_cfg: Let fw_cfg_add_from_generator() ret
Re: [PATCH-for-5.1] hw/nvram/fw_cfg: Let fw_cfg_add_from_generator() return boolean value
Thu, 23 Jul 2020 13:01:18 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 Thunderbird/52.9.1
+Igor, and question below
On 07/23/20 09:37, Markus Armbruster wrote:
> You must use ERRP_GUARD() in functions that dereference their @errp
> parameter (so that works even when the argument is null) or pass it to
> error_prepend() or error_append_hint() (so they get reached even when
> the argumentis &error_fatal).
> You should use Use ERRP_GUARD() to avoid clumsy error propagation.
> You should not use ERRP_GUARD() when propagation is not actually
Thank you for the explanation. :)
Two patches from a series (work in progress) that I'd like to raise:
- [PATCH 2/6] x86: cphp: prevent guest crash on CPU hotplug when broadcast SMI
is in use
- [PATCH 3/6] x86: cpuhp: refuse cpu hot-unplug request earlier if not supported
Both of these call error_append_hint(errp, ...). I think these functions
are never called against "error_fatal" (they are reached in "device_add"
and "device_del" monitor commands). But just for consistency with the
new rules, should these functions -- ich9_pm_device_pre_plug_cb() and
ich9_pm_device_unplug_request_cb() -- adopt ERRP_GUARD() in those
(If the answer is "yes", then could you please state that right under
those patches, so the feedback is easier for Igor to collect?
Plus I think commit e3fe3988d78 should be mentioned frequently, because
it's really helpful, and at least I wouldn't have remembered to check
"include/qapi/error.h" for the new rules; mea culpa :/)