linux-kernel - Re: [PATCH 01/15] cxl/aer/pci: Add CXL PCIe port error handler callbacks in AER service driver

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] [day] [month] [year] [list]

Message-ID: <671a9bb93ecce_10e5929419@dwillia2-xfh.jf.intel.com.notmuch>
Date: Thu, 24 Oct 2024 12:10:49 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: "Bowman, Terry" <terry.bowman@....com>, Dan Williams
	<dan.j.williams@...el.com>, <ming4.li@...el.com>,
	<linux-cxl@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-pci@...r.kernel.org>, <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>, <oohall@...il.com>,
	<Benjamin.Cheatham@....com>, <rrichter@....com>, <nathan.fontenot@....com>,
	<smita.koralahallichannabasappa@....com>
Subject: Re: [PATCH 01/15] cxl/aer/pci: Add CXL PCIe port error handler
 callbacks in AER service driver

Bowman, Terry wrote:
[..]
> > So, in general new operational models == new data structures and types.
> 
> Would you like to continue to use the pci_error_handlers for the CXL PCIe 
> endpoint device driver? Or do we change the CXL PCIe endpoint driver to 
> use the cxl_error_handlers ?

I would expect to extend with new 'cxl_error_handlers' support. 'Extend'
not 'replace' because a CXL endpoint could in fact be operating in pure
PCIe mode.

Otherwise, it is currently ambiguous what an error handler invocation is
signaling. In the new scheme fatal CXL errors are panics, while fatal
PCIe errors remain device resets.

So the question is how to distinguish those events without separate
entry points. Either the error (bus) type needs to be added as a
parameter to the callbacks or the error type is implied by the 'error
handlers' type. I would rather not go disturb the PCIe error handler
world by making them deal with an error type passed to existing
callbacks, so a new invocation regime seems appropriate.

I am open to other thoughts, but this seems the most maintainable way to
handle these parallel universes that both happen to fork from an AER
error source.