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

[Alison Schofield]

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 shaikhkamal2012@xxxxxxxxx. 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 shaikhkamal2012@xxxxxxxxx. 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 <shaikhkamal2012@xxxxxxxxx>
> >>> ---
> >>
> >> This looks good to me, so:
> >> Reviewed-by: Ben Cheatham <benjamin.cheatham@xxxxxxx>
> >>
> > 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.


This sounded interesting! I gave it a try with cxl_test and mce-inject,
and it looks like this can be tested without the QEMU CXL topology or the
forced cache_size hack.

I built with CONFIG_X86_MCE_INJECT=m and loaded cxl_test with its
existing ELC support:

# modprobe cxl_test extended_linear_cache=1
# cxl list -R
[
  {
    "region":"region0",
    "resource":70300293136384,
    "size":1073741824,
    "extended_linear_cache_size":536870912,
    "type":"ram",
    "interleave_ways":2,
    "interleave_granularity":4096,
    "decode_state":"commit",
    "locked":false
  }
]

Using 0x3ff010010000 as the injected SPA, I first injected the
corrected error from your example. On the patched kernel there was no
CXL offlining message, as expected.

I then changed only the status to the uncorrectable case:

# cd /sys/kernel/debug/mce-inject
# echo sw > flags
# echo 0xbc00000000000080 > status
# echo 0x80 > misc
# echo 0x3ff010010000 > addr
# echo 9 > bank

and got:

cxl_region region0: Offlining aliased SPA address0: 0x3ff030010000
Memory failure: 0x3ff030010: memory outside kernel control
mce: [Hardware Error]: CPU 0: Machine Check: 0 Bank 9: bc00000000000080
mce: [Hardware Error]: TSC 23c5a5a9188 ADDR 3ff010010000 MISC 80
mce: [Hardware Error]: PROCESSOR 0:50657 TIME 1786573477 SOCKET 0 APIC 0 microcode 5003302

So the cxl_test ELC plus mce-inject looks sufficient to exercise the
path: the CE is ignored with the patch, while the UC reaches the alias
offlining path and computes the expected alias.

The "memory outside kernel control" is because I did not put the
aliased memory into system RAM for this quick test.

This would be a test case addition for the the cxl-elc.sh unit test.
It seems like a tiny, close-the-barn-door-after-the-horse-got-out,
kind of test case, but maybe not?  Maybe it opens the door to more
things can do we mce-inject elsewhere?

I'll leave that to Shaikh if they want to add the new test case.

-- Alison


> 
> Thanks,
> Ben