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

[“William Roche]

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