Re: [PATCH v19 02/14] cxl/ras: Fix cxl_rch_get_aer_severity() wrong severity register
Terry Bowman <[email protected]>
| Newsgroups | org.kernel.vger.linux-acpi,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci |
|---|---|
| Message-ID | <[email protected]> |
On 9/3/26 03:35, 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. Also, I am currently on PTO this week and don’t have my work laptop, so I am responding from my personal email account. I’ll be back in the office Wednesday. 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 ishere: <https://lkml.org/lkml/2026/9/2/1629> (v20 3/9). Please let me know if you see any remaining concerns or corner cases that are not yet covered. Thanks again for your review and for pointing out the issue. - Terry