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

[Pierre Gondois <pierre.gondois@arm.com>]

On 9/29/26 18:35, Jonathan Cameron wrote:
> On Tue, 29 Sep 2026 09:45:59 +0200
> Pierre Gondois <pierre.gondois@arm.com> 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