On 31/03/17 16:10, Boris Ostrovsky wrote: > 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) Ha, you are right! So I can just fold the patches into one and turn some more functions into retuning void. Juergen > >> >> 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; > >