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

Groups > linux.kernel > #1250977 > unrolled thread

[PATCH] GHES: Fix cached error-status

Back to article view | Back to linux.kernel

Contents

  [PATCH] GHES: Fix cached error-status Davidlohr Bueso <dave@stgolabs.net> - 2015-10-19 20:00 +0200
    Re: [PATCH] GHES: Fix cached error-status Davidlohr Bueso <dave@stgolabs.net> - 2015-10-24 01:00 +0200
      RE: [PATCH] GHES: Fix cached error-status "Luck, Tony" <tony.luck@intel.com> - 2015-10-24 01:10 +0200
        Re: [PATCH] GHES: Fix cached error-status "Huang\, Ying" <ying.huang@linux.intel.com> - 2015-10-26 04:30 +0100
          Re: [PATCH] GHES: Fix cached error-status Borislav Petkov <bp@suse.de> - 2015-10-26 05:40 +0100
            Re: [PATCH] GHES: Fix cached error-status "Huang\, Ying" <ying.huang@linux.intel.com> - 2015-10-26 06:50 +0100

#1250977 — [PATCH] GHES: Fix cached error-status

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1255043

ping?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1255046

> 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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1255640

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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1255656

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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1255676

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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web