On 03/31/2017 07:19 AM, Juergen Gross wrote: > Error handling in upload_pm_data() is rather questionable: possible > errno values from called functions are or'ed together resulting in > strange return values: -EINVAL and -ENOMEM would e.g. result in > returning -EXDEV. And it doesn't matter anyway since noone checks return value. (not that OR-ing errors makes much sense) > > Fix this by bailing out early after the first error. I am not sure about this: why should we not try to load P states if C states failed to load? -boris > > Cc: stable@xxxxxxxxxxxxxxx > Signed-off-by: Juergen Gross <jgross@xxxxxxxx> > --- > drivers/xen/xen-acpi-processor.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/xen/xen-acpi-processor.c b/drivers/xen/xen-acpi-processor.c > index 23e391d..3659ed3 100644 > --- a/drivers/xen/xen-acpi-processor.c > +++ b/drivers/xen/xen-acpi-processor.c > @@ -283,8 +283,8 @@ static int upload_pm_data(struct acpi_processor *_pr) > if (_pr->flags.power) > err = push_cxx_to_hypervisor(_pr); > > - if (_pr->performance && _pr->performance->states) > - err |= push_pxx_to_hypervisor(_pr); > + if (!err && _pr->performance && _pr->performance->states) > + err = push_pxx_to_hypervisor(_pr); > > mutex_unlock(&acpi_ids_mutex); > return err;