Re: [PATCH] cxl/mce: Only act on uncorrected memory errors

On Wed, Aug 12, 2026 at 11:19:40AM -0500, Cheatham, Benjamin wrote:
> On 8/12/2026 10:59 AM, shaikh kamaluddin wrote:
> > [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> > 
> > On Mon, Aug 10, 2026 at 02:00:18PM -0500, Cheatham, Benjamin wrote:
> >> On 8/10/2026 1:30 PM, Shaikh Kamaluddin wrote:
> >>> [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >>>
> >>> cxl_handle_mce() offlines the aliased page of an ELC region on any
> >>> record with a usable address; it does not check MCI_STATUS_UC or
> >>> filter non-memory errors. uc_decode_notifier(), the equivalent
> >>> handler for plain memory on the same chain at the same priority,
> >>> filters on mce->severity and leaves corrected errors untouched.
> >>> cxl_handle_mce() has no such gate, so a corrected error - which
> >>> the generic handler ignores - still causes the alias to be
> >>> permanently retired via memory_failure().
> >>>
> >>> Corrected errors do reach the chain: machine_check_poll() logs
> >>> them via the same mce_gen_pool_process() path that feeds
> >>> x86_mce_decoder_chain, and cxl_extended_linear_cache_resize()
> >>> extends p->res to cover the DRAM half of the ELC pair, so a
> >>> routine DRAM CE carries an address inside the region resource.
> >>>
> >>> Filter the record as nfit_handle_mce() does. Commit fc08a4703a41
> >>> ("acpi, nfit: Fix the memory error check in nfit_handle_mce()") and
> >>> commit 5d96c9342c23 ("acpi/nfit, x86/mce: Handle only uncorrectable
> >>> machine checks") established this filter for an equivalent handler
> >>> on the same notifier chain; the consequence here is more severe, as
> >>> the CXL handler calls memory_failure() rather than recording a bad
> >>> block.
> >>>
> >>> mce_is_correctable() is used instead of copying
> >>> uc_decode_notifier()'s AO/DEFERRED test because the alias must
> >>> still be offlined on MCE_AR_SEVERITY, where kill_me_maybe() owns
> >>> the reported page but nothing owns the alias.
> >>>
> >>> Fixes: 516e5bd0b6bf ("cxl: Add mce notifier to emit aliased address for extended linear cache")
> >>>
> >>> Signed-off-by: Shaikh Kamaluddin <[email protected]>
> >>> ---
> >>
> >> This looks good to me, so:
> >> Reviewed-by: Ben Cheatham <[email protected]>
> >>
> > Thanks for review!
> >> If you have the time, could you also share a script that does the below testing on the list? It may
> >> be possible to integrate into the CXL testing suite (see https://github.com/pmem/ndctl.git), though
> >> the QEMU usage may throw a wrench in that. Even if it's not possible, having the tests out there
> >> for people to run would help with any future breakage.
> > Happy to share it. One question on where it'd fit best: ndctl
> > (github.com/pmem/ndctl.git) as you mentioned, or drivers/cxl's own
> > tools/testing/cxl/ in-tree? I'm open to either, or proposing it in
> > both if that's useful - happy to follow your lead on which is the
> > better home for it.
> > 
> 
> If looks like there's already some mock functions for extended linear cache in tools/testing/cxl, so
> I'd recommending trying to put it there to begin with. It may require updates to ndctl after the fact
> to run the test(s) as well. If that looks too involved then sending the script out to the list standalone
> should be fine. I don't know if anyone will pick it up, but it'll be searchable on lore if anyone wants
> to test this.
> 
> Thanks,
> Ben

Thanks Ben.

I took a closer look at the existing tools/testing/cxl ELC support. It already provides the mock ELC topology and uses the real CXL MCE notifier path, so based on Alison's testing it looks like no additional CE/UC-specific mock support should be required there.

I had initially tried the same cxl_test + mce-inject approach, but hit the current tools/testing/cxl build/wrap issue. With the proposed build fix applied, it builds for me now, although I am still debugging a crash when running the ELC setup. I am comparing my setup with Alison's working configuration before making any test changes.

Once that is resolved, my current plan is to extend the existing ndctl/test/cxl-elc.sh test to:

derive the SPA and expected alias dynamically from the ELC region,
inject a CE and verify the alias-offlining path is not reached, and
inject a UC and verify the expected alias-offlining path is still reached.

So I will first confirm that the existing tools/testing/cxl infrastructure is sufficient as-is, then share the cxl-elc.sh changes here for review before sending a separate ndctl patch.

Thanks,
Shaikh