linux-kernel - Re: [PATCH v7 04/17] PCI/AER: Modify AER driver logging to report CXL or PCIe bus error type

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <67acfd24a4245_2d1e29437@dwillia2-xfh.jf.intel.com.notmuch>
Date: Wed, 12 Feb 2025 11:57:24 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: "Bowman, Terry" <terry.bowman@....com>, Dan Williams
	<dan.j.williams@...el.com>, <linux-cxl@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-pci@...r.kernel.org>,
	<nifan.cxl@...il.com>, <dave@...olabs.net>, <jonathan.cameron@...wei.com>,
	<dave.jiang@...el.com>, <alison.schofield@...el.com>,
	<vishal.l.verma@...el.com>, <bhelgaas@...gle.com>, <mahesh@...ux.ibm.com>,
	<ira.weiny@...el.com>, <oohall@...il.com>, <Benjamin.Cheatham@....com>,
	<rrichter@....com>, <nathan.fontenot@....com>,
	<Smita.KoralahalliChannabasappa@....com>, <lukas@...ner.de>,
	<ming.li@...omail.com>, <PradeepVineshReddy.Kodamati@....com>
Subject: Re: [PATCH v7 04/17] PCI/AER: Modify AER driver logging to report
 CXL or PCIe bus error type

Bowman, Terry wrote:
[..]
> > Reviewed-by: Dan Williams <dan.j.williams@...el.com>
> Ok. I can add is_cxl to 'struct aer_err_info'. Shall I set it by reading the
> alternate protocol link state?

I am thinking no because dev->is_cxl at least indicates that a CXL link
was up at some point, and racing CXL link down is not something the
error core can reasonably mitigate.

In the end I think that it should be something like:

   info->is_cxl = dev->is_cxl && is_internal_error()

...on the expectation that a CXL device is unlikely to multiplex
internal errors across CXL protocol error events and device-specific
internal events. Even if a device *did* multiplex those I think it is
reasonable for the kernel to treat a device-specific UCE the same as a
CXL protocol UCE and panic the system.