Re: [PATCH v19 02/14] cxl/ras: Fix cxl_rch_get_aer_severity() wrong severity register

From: Bowman, Terry

Date: Wed Sep 09 2026 - 12:25:09 EST


On 9/3/2026 3:35 AM, Lukas Wunner wrote:
> Hi Terry,
>
> You've submitted v20 of this series, but the following
> questions haven't been addressed yet AFAICS. I'd be
> grateful if you could take a look:
>
> On Sun, Aug 09, 2026 at 05:57:23PM +0200, Lukas Wunner wrote:
>> Am I missing something? Is a scenario ever conceivable where the RCEC
>> receives a message with different severity than what is inferred from
>> the registers by cxl_rch_get_aer_severity()?
> [...]
>> These so-called Advisory Non-Fatal Errors set one bit in the Correctable
>> Error Status Register (Advisory Non-Fatal Error Status, bit 13) and
>> additionally one or more bits in the Uncorrectable Error Status Register
>> (see the commit for details).
>>
>> cxl_rch_get_aer_severity() is not able to cope with such errors and
>> will incorrectly infer that the severity is AER_NONFATAL.
>>
>> Now I *think* this is not a problem because Advisory Non-Fatal Errors
>> are masked by default and the commit only unmasks them on regular PCI
>> devices, not in the RCRB of a CXL device. Only once bit 13 in the
>> Correctable Error Mask Register is cleared in the RCRB will
>> cxl_rch_get_aer_severity() fail. Right?
>
> Thanks,
>
> Lukas

Hi Lukas,

I’m sorry for missing your August 9 reply.

Thanks for pointing out the issue with CE and UCE errors reported
simultaneously. I agree this is a problem and have addressed it in v20.

In v20 I remove the unused `cxl_rch_get_aer_severity()` helper, take a
snapshot of the AER registers before calling `pci_print_aer()`, and now
handle the CE and UCE parts in separate blocks. The UCE status is logged
unconditionally, which prevents a fatal record from being lost under the
advisory‑non‑fatal path. These changes directly address the scenario you
raised for v19 and also cover any other situation where a CE and a UCE
are co‑logged. The patch is here: <https://lkml.org/lkml/2026/9/2/1629>
(v20 3/9).

Jonathan added a comment looking for your feedback on if the issue should
be solved by changing pci_print_aer() to be non-destructive instead. It
is here:
https://lore.kernel.org/linux-cxl/20260908020608.56e8c443@jic23-huawei/

- Terry