* [PATCH] GHES: Fix cached error-status
@ 2015-10-19 17:55 Davidlohr Bueso
2015-10-23 22:50 ` Davidlohr Bueso
0 siblings, 1 reply; 6+ messages in thread
From: Davidlohr Bueso @ 2015-10-19 17:55 UTC (permalink / raw)
To: Huang Ying
Cc: Rafael J. Wysocki, Borislav Petkov, Tony Luck, linux-acpi,
linux-kernel
In ghes_estatus_cached() we currently have a situation where
we can break out of the loop before examining all the possible
estatus_caches. Move the 'break' statement inside of the 'if',
such that an otherwise possibly missed cache is acknowledged
and the function returns the proper value.
Introduced by 152cef40a808d (ACPI, APEI, GHES, Error records
content based throttle).
Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
---
Hi,
I found this accidentally and have no idea if it is correct, but
seems to be a case of a misplaced break. If this is not the case,
then it is a very weird way of using a for-loop, and should probably
be rewritten -- and there are other funky places in this file...
100% untested.
Thanks,
Davidlohr
drivers/acpi/apei/ghes.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 3dd9c46..3fda4a2 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -541,9 +541,10 @@ static int ghes_estatus_cached(struct acpi_hest_generic_status *estatus)
continue;
atomic_inc(&cache->count);
now = sched_clock();
- if (now - cache->time_in < GHES_ESTATUS_IN_CACHE_MAX_NSEC)
+ if (now - cache->time_in < GHES_ESTATUS_IN_CACHE_MAX_NSEC) {
cached = 1;
- break;
+ break;
+ }
}
rcu_read_unlock();
return cached;
--
2.1.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] GHES: Fix cached error-status
2015-10-19 17:55 [PATCH] GHES: Fix cached error-status Davidlohr Bueso
@ 2015-10-23 22:50 ` Davidlohr Bueso
2015-10-23 23:05 ` Luck, Tony
0 siblings, 1 reply; 6+ messages in thread
From: Davidlohr Bueso @ 2015-10-23 22:50 UTC (permalink / raw)
To: Huang Ying
Cc: Rafael J. Wysocki, Borislav Petkov, Tony Luck, linux-acpi,
linux-kernel
ping?
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [PATCH] GHES: Fix cached error-status
2015-10-23 22:50 ` Davidlohr Bueso
@ 2015-10-23 23:05 ` Luck, Tony
2015-10-26 3:20 ` Huang, Ying
0 siblings, 1 reply; 6+ messages in thread
From: Luck, Tony @ 2015-10-23 23:05 UTC (permalink / raw)
To: Davidlohr Bueso, Huang, Ying
Cc: Rafael J. Wysocki, Borislav Petkov, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org
> ping?
I'm not actually sure that the code is wrong. As you say it is a pretty strange loop.
We seem to want to look at a bunch of conditions, and use "continue" to ignore
bits until we find one that we like the look of. Perhaps as soon as we do, we want
to believe it to get our return value? Perhaps the code knows that we won't find
another section that matches all the tests, so it isn't worth going around the loop
again.
Ying: You wrote this code 4 years ago. Any recollections of why it looks like it does?
-Tony
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] GHES: Fix cached error-status
2015-10-23 23:05 ` Luck, Tony
@ 2015-10-26 3:20 ` Huang, Ying
2015-10-26 4:30 ` Borislav Petkov
0 siblings, 1 reply; 6+ messages in thread
From: Huang, Ying @ 2015-10-26 3:20 UTC (permalink / raw)
To: Luck, Tony
Cc: Davidlohr Bueso, Huang, Ying, Rafael J. Wysocki, Borislav Petkov,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Hi, Tony,
"Luck, Tony" <tony.luck@intel.com> writes:
>> ping?
>
> I'm not actually sure that the code is wrong. As you say it is a pretty strange loop.
>
> We seem to want to look at a bunch of conditions, and use "continue" to ignore
> bits until we find one that we like the look of. Perhaps as soon as we do, we want
> to believe it to get our return value? Perhaps the code knows that we won't find
> another section that matches all the tests, so it isn't worth going around the loop
> again.
>
> Ying: You wrote this code 4 years ago. Any recollections of why it looks like it does?
Sorry for late. I read the code again, and found the although the
original code is a little tricky, it actually works.
In ghes_estatus_caches[], for caches with same contents, the cache with
biggest (newest) cache->time_in should be the first. So if we found one
cache with too small (old) cache->time_in, we can say there are no cache
with same contents and bigger (newer) cache->time_in, so that we can
make decision (break) earlier.
Best Regards,
Huang, Ying
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] GHES: Fix cached error-status
2015-10-26 3:20 ` Huang, Ying
@ 2015-10-26 4:30 ` Borislav Petkov
2015-10-26 5:43 ` Huang, Ying
0 siblings, 1 reply; 6+ messages in thread
From: Borislav Petkov @ 2015-10-26 4:30 UTC (permalink / raw)
To: Huang, Ying
Cc: Luck, Tony, Davidlohr Bueso, Huang, Ying, Rafael J. Wysocki,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
On Mon, Oct 26, 2015 at 11:20:35AM +0800, Huang, Ying wrote:
> In ghes_estatus_caches[], for caches with same contents, the cache with
> biggest (newest) cache->time_in should be the first. So if we found one
> cache with too small (old) cache->time_in, we can say there are no cache
> with same contents and bigger (newer) cache->time_in, so that we can
> make decision (break) earlier.
Well, for starters, this should be documented in the code so that people
looking at it would not need to scratch their heads over that break
statement there.
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] GHES: Fix cached error-status
2015-10-26 4:30 ` Borislav Petkov
@ 2015-10-26 5:43 ` Huang, Ying
0 siblings, 0 replies; 6+ messages in thread
From: Huang, Ying @ 2015-10-26 5:43 UTC (permalink / raw)
To: Borislav Petkov
Cc: Luck, Tony, Davidlohr Bueso, Huang, Ying, Rafael J. Wysocki,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Borislav Petkov <bp@suse.de> writes:
> On Mon, Oct 26, 2015 at 11:20:35AM +0800, Huang, Ying wrote:
>> In ghes_estatus_caches[], for caches with same contents, the cache with
>> biggest (newest) cache->time_in should be the first. So if we found one
>> cache with too small (old) cache->time_in, we can say there are no cache
>> with same contents and bigger (newer) cache->time_in, so that we can
>> make decision (break) earlier.
>
> Well, for starters, this should be documented in the code so that people
> looking at it would not need to scratch their heads over that break
> statement there.
Yes. Will do it.
Best Regards,
Huang, Ying
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-10-26 5:43 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-19 17:55 [PATCH] GHES: Fix cached error-status Davidlohr Bueso
2015-10-23 22:50 ` Davidlohr Bueso
2015-10-23 23:05 ` Luck, Tony
2015-10-26 3:20 ` Huang, Ying
2015-10-26 4:30 ` Borislav Petkov
2015-10-26 5:43 ` Huang, Ying
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).