| Message ID | 20151019175554.GB3367@linux-uzut.site (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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
> 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
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
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.
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 --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;
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(-)