Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1503186 > unrolled thread

[PATCH] acpi/apei: Fix in-correct return value

Started byPunit Agrawal <punit.agrawal@arm.com>
First post2016-10-18 18:10 +0200
Last post2016-10-23 02:10 +0200
Articles 6 — 4 participants

Back to article view | Back to linux.kernel

Contents

  [PATCH] acpi/apei: Fix in-correct return value Punit Agrawal <punit.agrawal@arm.com> - 2016-10-18 18:10 +0200
    Re: [PATCH] acpi/apei: Fix in-correct return value "Baicar, Tyler" <tbaicar@codeaurora.org> - 2016-10-20 22:00 +0200
      Re: [PATCH] acpi/apei: Fix in-correct return value Punit Agrawal <punit.agrawal@arm.com> - 2016-10-21 17:00 +0200
    Re: [PATCH] acpi/apei: Fix in-correct return value "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-10-21 23:30 +0200
      Re: [PATCH] acpi/apei: Fix in-correct return value Borislav Petkov <bp@suse.de> - 2016-10-22 19:40 +0200
        Re: [PATCH] acpi/apei: Fix in-correct return value "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-10-23 02:10 +0200

#1503186 — [PATCH] acpi/apei: Fix in-correct return value

FromPunit Agrawal <punit.agrawal@arm.com>
Date2016-10-18 18:10 +0200
Subject[PATCH] acpi/apei: Fix in-correct return value
Message-ID<stF7J-42I-49@gated-at.bofh.it>
Although ghes_proc tests for error while reading the error status, it
always return success (0). Fix this by propagating the return value.

Fixes: d334a49113a4a33 ("ACPI, APEI, Generic Hardware Error Source memory error support")
Signed-of-by: Punit Agrawal <punit.agrawa.@arm.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
---
 drivers/acpi/apei/ghes.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index f0a029e..0d099a2 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -662,7 +662,7 @@ static int ghes_proc(struct ghes *ghes)
 	ghes_do_proc(ghes, ghes->estatus);
 out:
 	ghes_clear_estatus(ghes);
-	return 0;
+	return rc;
 }
 
 static void ghes_add_timer(struct ghes *ghes)
-- 
2.9.3

[toc] | [next] | [standalone]

#1505213

From"Baicar, Tyler" <tbaicar@codeaurora.org>
Date2016-10-20 22:00 +0200
Message-ID<surFn-3wn-7@gated-at.bofh.it>
In reply to#1503186
On 10/18/2016 10:07 AM, Punit Agrawal wrote:
> Although ghes_proc tests for error while reading the error status, it
> always return success (0). Fix this by propagating the return value.
>
> Fixes: d334a49113a4a33 ("ACPI, APEI, Generic Hardware Error Source memory error support")
> Signed-of-by: Punit Agrawal <punit.agrawa.@arm.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Len Brown <lenb@kernel.org>
Tested-by: Tyler Baicar <tbaicar@codeaurora.org>

Thanks,
Tyler
> ---
>   drivers/acpi/apei/ghes.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index f0a029e..0d099a2 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -662,7 +662,7 @@ static int ghes_proc(struct ghes *ghes)
>   	ghes_do_proc(ghes, ghes->estatus);
>   out:
>   	ghes_clear_estatus(ghes);
> -	return 0;
> +	return rc;
>   }
>   
>   static void ghes_add_timer(struct ghes *ghes)

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

[toc] | [prev] | [next] | [standalone]

#1506026

FromPunit Agrawal <punit.agrawal@arm.com>
Date2016-10-21 17:00 +0200
Message-ID<suJsB-73K-1@gated-at.bofh.it>
In reply to#1505213
"Baicar, Tyler" <tbaicar@codeaurora.org> writes:

> On 10/18/2016 10:07 AM, Punit Agrawal wrote:
>> Although ghes_proc tests for error while reading the error status, it
>> always return success (0). Fix this by propagating the return value.
>>
>> Fixes: d334a49113a4a33 ("ACPI, APEI, Generic Hardware Error Source memory error support")
>> Signed-of-by: Punit Agrawal <punit.agrawa.@arm.com>
>> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
>> Cc: Len Brown <lenb@kernel.org>
> Tested-by: Tyler Baicar <tbaicar@codeaurora.org>

Thanks for taking the patch for a spin.

Hopefully Rafael can pick the patch as a fixes for the next rc.


>
> Thanks,
> Tyler
>> ---
>>   drivers/acpi/apei/ghes.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index f0a029e..0d099a2 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -662,7 +662,7 @@ static int ghes_proc(struct ghes *ghes)
>>   	ghes_do_proc(ghes, ghes->estatus);
>>   out:
>>   	ghes_clear_estatus(ghes);
>> -	return 0;
>> +	return rc;
>>   }
>>     static void ghes_add_timer(struct ghes *ghes)

[toc] | [prev] | [next] | [standalone]

#1506307

From"Rafael J. Wysocki" <rjw@rjwysocki.net>
Date2016-10-21 23:30 +0200
Message-ID<suPy1-2Jv-19@gated-at.bofh.it>
In reply to#1503186
On Tuesday, October 18, 2016 05:07:19 PM Punit Agrawal wrote:
> Although ghes_proc tests for error while reading the error status, it
> always return success (0). Fix this by propagating the return value.
> 
> Fixes: d334a49113a4a33 ("ACPI, APEI, Generic Hardware Error Source memory error support")
> Signed-of-by: Punit Agrawal <punit.agrawa.@arm.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Len Brown <lenb@kernel.org>
> ---
>  drivers/acpi/apei/ghes.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index f0a029e..0d099a2 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -662,7 +662,7 @@ static int ghes_proc(struct ghes *ghes)
>  	ghes_do_proc(ghes, ghes->estatus);
>  out:
>  	ghes_clear_estatus(ghes);
> -	return 0;
> +	return rc;
>  }
>  
>  static void ghes_add_timer(struct ghes *ghes)
> 

Boris, all fine here?

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]

#1506566

FromBorislav Petkov <bp@suse.de>
Date2016-10-22 19:40 +0200
Message-ID<sv8qZ-6pE-3@gated-at.bofh.it>
In reply to#1506307
On Fri, Oct 21, 2016 at 11:28:29PM +0200, Rafael J. Wysocki wrote:
> Boris, all fine here?

Short answer: Yeah, looks ok to me.

Longer answer: I mean, this way ghes_proc() *actually* propagates the
return value of ghes_read_estatus() and we don't do any processing if it
failed.

Which doesn't really tell me a whole lot about the actual processing,
i.e., what ghes_do_proc() did.

But ghes_do_proc() doesn't return anything and ghes_proc()'s retval is
used only in contexts where we're asking whether something got processed
or not.

And for that, that fix is adequate. So:

Reviewed-by: Borislav Petkov <bp@suse.de>

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--

[toc] | [prev] | [next] | [standalone]

#1506618

From"Rafael J. Wysocki" <rjw@rjwysocki.net>
Date2016-10-23 02:10 +0200
Message-ID<svewq-1X7-3@gated-at.bofh.it>
In reply to#1506566
On Saturday, October 22, 2016 06:37:35 PM Borislav Petkov wrote:
> On Fri, Oct 21, 2016 at 11:28:29PM +0200, Rafael J. Wysocki wrote:
> > Boris, all fine here?
> 
> Short answer: Yeah, looks ok to me.
> 
> Longer answer: I mean, this way ghes_proc() *actually* propagates the
> return value of ghes_read_estatus() and we don't do any processing if it
> failed.
> 
> Which doesn't really tell me a whole lot about the actual processing,
> i.e., what ghes_do_proc() did.
> 
> But ghes_do_proc() doesn't return anything and ghes_proc()'s retval is
> used only in contexts where we're asking whether something got processed
> or not.
> 
> And for that, that fix is adequate. So:
> 
> Reviewed-by: Borislav Petkov <bp@suse.de>

Thanks!

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web