diff mbox

GHES: Fix cached error-status

Message ID 20151019175554.GB3367@linux-uzut.site (mailing list archive)
State Not Applicable, archived
Headers show

Commit Message

Davidlohr Bueso Oct. 19, 2015, 5:55 p.m. UTC
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(-)

Comments

Davidlohr Bueso Oct. 23, 2015, 10:50 p.m. UTC | #1
ping?
--
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
Tony Luck Oct. 23, 2015, 11:05 p.m. UTC | #2
> 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
--
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
Huang Ying Oct. 26, 2015, 3:20 a.m. UTC | #3
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
--
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
Borislav Petkov Oct. 26, 2015, 4:30 a.m. UTC | #4
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.
Huang Ying Oct. 26, 2015, 5:43 a.m. UTC | #5
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
--
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
diff mbox

Patch

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;