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

[Jonathan Cameron]

On Wed, 7 Oct 2026 15:35:08 +0200
Pierre Gondois <pierre.gondois@xxxxxxx> wrote:

> 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(), ...

Yes - if that's the cleanest path to not modify existing userspace ABI
(and ras tracepoints definitely count as that).


Jonathan
> 
> Regards,
> 
> Pierre
>