linux-kernel - Re: [PATCH v4 3/3] PCI/AER: Report fatal errors of RCiEP and EP if link recoverd

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: <54nug57urubw5uhrwrdos3s3kta2r4qovzb6cf2mntc7kiora5@lg3p7vjmrvb3>
Date: Thu, 12 Jun 2025 16:16:38 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: 
	Sathyanarayanan Kuppuswamy <sathyanarayanan.kuppuswamy@...ux.intel.com>, Shuai Xue <xueshuai@...ux.alibaba.com>
Cc: linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linuxppc-dev@...ts.ozlabs.org, bhelgaas@...gle.com, kbusch@...nel.org, mahesh@...ux.ibm.com, 
	oohall@...il.com, Jonathan.Cameron@...wei.com, terry.bowman@....com, 
	tianruidong@...ux.alibaba.com
Subject: Re: [PATCH v4 3/3] PCI/AER: Report fatal errors of RCiEP and EP if
 link recoverd

On Sun, Mar 02, 2025 at 07:43:41PM -0800, Sathyanarayanan Kuppuswamy wrote:
> 
> On 2/16/25 6:42 PM, Shuai Xue wrote:
> > The AER driver has historically avoided reading the configuration space of
> > an endpoint or RCiEP that reported a fatal error, considering the link to
> > that device unreliable. Consequently, when a fatal error occurs, the AER
> > and DPC drivers do not report specific error types, resulting in logs like:
> > 
> >    pcieport 0000:30:03.0: EDR: EDR event received
> >    pcieport 0000:30:03.0: DPC: containment event, status:0x0005 source:0x3400
> >    pcieport 0000:30:03.0: DPC: ERR_FATAL detected
> >    pcieport 0000:30:03.0: AER: broadcast error_detected message
> >    nvme nvme0: frozen state error detected, reset controller
> >    nvme 0000:34:00.0: ready 0ms after DPC
> >    pcieport 0000:30:03.0: AER: broadcast slot_reset message
> > 
> > AER status registers are sticky and Write-1-to-clear. If the link recovered
> > after hot reset, we can still safely access AER status of the error device.
> > In such case, report fatal errors which helps to figure out the error root
> > case.
> > 
> > After this patch, the logs like:
> > 
> >    pcieport 0000:30:03.0: EDR: EDR event received
> >    pcieport 0000:30:03.0: DPC: containment event, status:0x0005 source:0x3400
> >    pcieport 0000:30:03.0: DPC: ERR_FATAL detected
> >    pcieport 0000:30:03.0: AER: broadcast error_detected message
> >    nvme nvme0: frozen state error detected, reset controller
> >    pcieport 0000:30:03.0: waiting 100 ms for downstream link, after activation
> >    nvme 0000:34:00.0: ready 0ms after DPC
> >    nvme 0000:34:00.0: PCIe Bus Error: severity=Uncorrectable (Fatal), type=Data Link Layer, (Receiver ID)
> >    nvme 0000:34:00.0:   device [144d:a804] error status/mask=00000010/00504000
> >    nvme 0000:34:00.0:    [ 4] DLP                    (First)
> >    pcieport 0000:30:03.0: AER: broadcast slot_reset message
> 
> IMO, above info about device error details is more of a debug info. Since
> the
> main use of this info use to understand more details about the recovered
> DPC error. So I think is better to print with debug tag. Lets see what
> others
> think.
> 

My two cents: All AER logs are mostly error messages, so I don't see why this
one should be a debug message. But having said that, this new error log may
confuse users as if a new AER error is received post recovery. So adding
something that specifies that this belong to the previous AER error would be
good IMO.

- Mani

-- 
மணிவண்ணன் சதாசிவம்