Messages in this thread Patch in this message | | | From | “William Roche <> | Subject | [PATCH v1] RAS/CEC: Memory Corrected Errors consistent event filtering | Date | Fri, 26 Mar 2021 14:30:29 -0400 |
| |
From: William Roche <william.roche@oracle.com>
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@oracle.com> ---
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
| |