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@xxxxxxx>
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
