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

[Jonathan Cameron]

On Fri, 30 Oct 2026 18:16:06 +0100
Pierre Gondois <pierre.gondois@xxxxxxx> wrote:

> On 10/30/26 16:19, Jonathan Cameron wrote:
> > On Fri, 30 Oct 2026 12:51:47 +0100
> > Pierre Gondois <pierre.gondois@xxxxxxx> wrote:
> >  
> >> On 10/25/26 00:05, Ashok Raj wrote:  
> >>> On Fri, Oct 23, 2026 at 05:04:05PM -0700, Jonathan Cameron wrote:  
> >>>> On Sat, 24 Oct 2026 00:40:33 +0200
> >>>> Mauro Carvalho Chehab <mchehab+huawei@xxxxxxxxxx> wrote:
> >>>>     
> >>>>> On Fri, 23 Oct 2026 14:26:21 -0700
> >>>>> Jonathan Cameron <jonathan.cameron@xxxxxxxxxxxxxxxx> wrote:
> >>>>>     
> >>>>>> On Thu, 22 Oct 2026 09:07:25 +0200
> >>>>>> Pierre Gondois <pierre.gondois@xxxxxxx> wrote:
> >>>>>>         
> >>>>>>> On 10/20/26 19:10, Jonathan Cameron wrote:  
> >>>>>>>> On Mon, 19 Oct 2026 22:38:39 +0200
> >>>>>>>> Pierre Gondois <pierre.gondois@xxxxxxx> wrote:
> >>>>>>>>            
> >>>>>>>>> The support is mostly duplicated from Memory Error Section handling.
> >>>>>>>>> Other than differences coming from the content of  Memory Error
> >>>>>>>>> Section 1 and 2, differences in the support are:
> >>>>>>>>>
> >>>>>>>>> - v2 do not rely on a compact "struct cper_mem_err_compact" struct.
> >>>>>>>>> This structure was used to support older versions of the Memory
> >>>>>>>>> Error Section (1). This is not needed for the new structure.
> >>>>>>>>>
> >>>>>>>>> - The compact version is also used by the tracing framework.
> >>>>>>>>> To avoid relying and propagating a non-standard record format,
> >>>>>>>>> through trace event (cf. extlog_mem event) the new trace event
> >>>>>>>>> prints each field individually.
> >>>>>>>>>
> >>>>>>>>> The last patch of the serie was only build-tested due to the
> >>>>>>>>> absence of relevant hardware. apei_mce_report_mem_error() and
> >>>>>>>>> arch_apei_report_mem_error() implementations were also removed since
> >>>>>>>>> last version.
> >>>>>>>>>
> >>>>>>>>> It will also require a proper handling from the rasdaemon. Applying
> >>>>>>>>> this last patch without rasdaemon support will silent the reports of
> >>>>>>>>> Memory Error Section 2 error, cf. ras_userspace_consumers() check.  
> >>>>>>>> Hi Pierre,
> >>>>>>>>
> >>>>>>>> I'd slow down a bit.  We are mid merge window and convention is normally
> >>>>>>>> one version a week or so anyway.  Better to gather up feedback from
> >>>>>>>> a number of folk and spin only one revision to cover it all.
> >>>>>>>>            
> >>>>>>> Hello Jonathan,
> >>>>>>>
> >>>>>>> Ok sure, as the v1 was reviewed quickly I thought there was a chance
> >>>>>>> of having the serie accepted quickly aswell. I ll wait a bit more.
> >>>>>>>
> >>>>>>> Thanks for the review,
> >>>>>>>
> >>>>>>> Pierre
> >>>>>>>           
> >>>>>> A general question that came up in a related thread with one of
> >>>>>> our RAS architects. How does firmware decide what to send?  As far as
> >>>>>> I can tell firwmare has no way to know whether the OS understands the CPER
> >>>>>> Memory Section 2.
> >>>>>>
> >>>>>> So options that come to mind.
> >>>>>> 1. Firmware must send a CPER with both Memory Section and Memory Section 2.  
> >>>>> Please don't do this: this would require either Kernespace or userspace to
> >>>>> discard one of the reports, only if the other one is there, which can be
> >>>>> tricky. Could be done more easily at userspace, but only if some database
> >>>>> support is enabled, but, at least on rasdaemon, this is an optional module.  
> >>>> Good. That confirms my view that is horrible.  
> >>> Hi Jonathan,
> >>>
> >>> I agree that an _OSC capability is the right long-term solution.
> >>>
> >>> Firmware should select one native CPER format based on OS support, rather
> >>> than emit both Section 1 and Section 2 and leave deduplication to the OS
> >>> or userspace.
> >>>
> >>> For a Section 2-capable kernel, we may still avoid a second GHES notifier
> >>> chain: preserve the existing struct cper_sec_mem_err * contract and give
> >>> it a lossy Section 1 projection of a Section 2 record. The conversion must
> >>> translate validation bits and clear validity for values that cannot be
> >>> represented, rather than truncate them.  
> >> I understand we might want to emit a new extlog_mem2_event and a lossy
> >> extlog_mem_event for legacy userspace, but I'm not sure to follow how
> >> you want to do it.
> >>
> >> Do you suggest that we only need one notifier (ghes_report_mem_chain)
> >> and that we should not add ghes_report_mem2_chain ? This would mean
> >> that the .notifier_call (= ghes_edac_report_mem_error) should handle
> >> both cper_sec_mem_err/cper_sec_mem_err2 struct.
> >>
> >> Another solution would be to keep the ghes_report_mem2_chain,
> >> which would be responsible of creating the lossy v1 struct and
> >> triggering the original ghes_report_mem_chain.
> >>  
> >>> That preserves legacy EDAC consumers, but cannot carry all Section 2 data.
> >>> Updated userspace needs the native Section 2 payload through a
> >>> full-fidelity path, such as the existing GUID-tagged raw CPER event.
> >>>
> >>> This does mean an updated userspace listener may receive both the legacy
> >>> EDAC summary and the raw Section 2 record for the same firmware error.
> >>> They are two kernel views, not two firmware reports. We should therefore
> >>> add a shared GHES record/section ID to both events, so userspace can
> >>> correlate them reliably; address and timestamp are not sufficient.
> >>>
> >>> So _OSC solves firmware selection for old versus new kernels, while a
> >>> Section 1 projection plus the raw payload handles legacy versus updated
> >>> consumers on a new kernel.
> >>>
> >>> Thoughts?  
> >> This will put more burden on the firmware, but this seems the right
> >> thing to do. I ll share the thread with the group working more closely
> >> on the architecture aswell,  
> > We have will have a code first proposal for the _OSC part shortly. Just going
> > through internal review.  I'll make sure you + others here are on the +CC.  
> 
> Ok thanks,
> If you can also also add Mark Brown <broonie@xxxxxxxxxx>
> 
https://lore.kernel.org/linux-acpi/20261030143802.0000231d@xxxxxxxxxxxxxxxx/

I started a new thread so it wasn't too buried.

Thanks

Jonathan