[PATCH v1] RAS/CEC: Memory Corrected Errors consistent event filtering

From: “William Roche
Date: Fri Mar 26 2021 - 14:32:12 EST


From: William Roche <william.roche@xxxxxxxxxx>

The Corrected Error events collected by the cec_add_elem() have to be
consistently filtered out.
We fix the case where the value of find_elem() to find the slot of a pfn
was mistakenly used as the return value of the function.
Now the MCE notifiers chain relying on MCE_HANDLED_CEC would only report
filtered corrected errors that reached the action threshold.

Signed-off-by: William Roche <william.roche@xxxxxxxxxx>
---

Notes:
Some machines are reporting Corrected Errors events without any
information about a PFN Soft-offlining or Invalid pfn (report given by
the EDAC module or the mcelog daemon).

A research showed that it reflected the first occurrence of a CE error
on the system which should have been filtered by the RAS_CEC component.
We could also notice that if 2 PFNs are impacted by CE errors, the PFN
on the non-zero slot gets its CE errors reported every-time instead of
being filtered out.

This problem has appeared with the introduction of commit
de0e0624d86ff9fc512dedb297f8978698abf21a where the filtering logic has
been modified.

Could you please review this small suggested fix ?

Thanks in advance for any feedback you could have.
William.

drivers/ras/cec.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/ras/cec.c b/drivers/ras/cec.c
index ddecf25..fdb9762 100644
--- a/drivers/ras/cec.c
+++ b/drivers/ras/cec.c
@@ -313,7 +313,7 @@ static int cec_add_elem(u64 pfn)
{
struct ce_array *ca = &ce_arr;
unsigned int to = 0;
- int count, ret = 0;
+ int count, ret;

/*
* We can be called very early on the identify_cpu() path where we are
@@ -372,6 +372,9 @@ static int cec_add_elem(u64 pfn)
goto unlock;
}

+ /* action threshold not reached */
+ ret = 0;
+
ca->decay_count++;

if (ca->decay_count >= CLEAN_ELEMS)
--
1.8.3.1