Re: [RFC PATCH 0/6] CPER: Add Memory Error Section 2 support

[Pierre Gondois]

On 9/29/26 18:35, Jonathan Cameron wrote:
> On Tue, 29 Sep 2026 09:45:59 +0200
> Pierre Gondois <pierre.gondois@xxxxxxx> wrote:
>
> > Add support for Memory Error Section 2 records.
> >
> > Extend cper_mem_err_compact to hold both legacy and section-2 records.
> > Add a common parser and convert the CPER, GHES, EDAC, extlog and x86 APEI
> > paths to use it.
> >
> > The extlog_mem_event payload layout changes with this series.
> > Compatibility with existing userspace decoders still needs to be
> > addressed. More specifically, the rasdaemon relies on the current
> > struct cper_mem_err_compact definition.
> > Either:
> > A-
> > this patchset should not modify struct cper_mem_err_compact and
> > create a new structure to handle Memory Error Section 2 events,
> > but this would ignore the similarities of Memory Error Section (1)/2
> > B-
> > userspace should not rely on the struct cper_mem_err_compact
> > layout. extlog_mem_event trace events should instead emit data
> > that relies on the actual layout of the CPER records, as defined
> > in the ACPI spec.
> >
> > I am looking for guidance on how to handle the above question.
> > Current implementation lean toward B, but emits data in the trace
> > event that maps the new/updated struct cper_mem_err_compact.
> My initial thought is a no to modifying the usespace ABI.
>
> It isn't particularly painful to just have separate handling code
> for the new record.  Unfortunately the ext_log tracepoints don't
> split out the fields in a fashion that would let you change
> the structure.  Other RAS tracepoints do it field by field which
> would have been possible to augment - even then it would have
> required care to deal with field size changes.
>
> It may be worth considering a much more 'expanded' tracepoint for
> memory error section 2 to reduce similar future extension problems.
> That is express ever field and don't use a compact structure at all.
>
> Mauro, perhaps you can give input on what works better over the
> long term?
Just to be sure I understand correclty, this means that you would prefer
to add a 'struct cper_mem_err2_compact'. All the functions currently using
'struct cper_mem_err_compact' or 'struct cper_sec_mem_err' as input/output
parameter would have to be duplicated right ?
E.g. arch_apei_report_mem_error(), cper_dimm_err_location(), ...

Regards,

Pierre