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

[Jonathan Cameron]

On Mon, 2 Nov 2026 12:33:16 +0100
Pierre Gondois <pierre.gondois@xxxxxxx> wrote:

> On 10/30/26 22:40, Jonathan Cameron wrote:
> > 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.  
> 
> [1] Not sure about the outcome of the above.

Needs input from the RAS maintainers etc - particularly on x86.

> 
> >>>>     
> >>>>> 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 !
> 
> Just to be sure, the _OSC discussion should not prevent this patchset
> to proceed right ? I think there is only [1] which I m not sure about the
> outcome otherwise,

It doesn't prevent this going forwards, but reality is I think no platform
is going to surface any Memory Section 2 errors until we have the _OSC.  

It should be a trivial addition though to pop the _OSC assuming we get
it in the spec.

thanks,

Jonathan

> 
> Regards,
> 
> Pierre
>