linux-kernel - Re: [PATCH pci-next] pci/edr: Ignore Surprise Down error on hot removal

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: <f9fd8861-6bbb-469d-b0cb-2edc8598ecca@linux.intel.com>
Date: Tue, 5 Mar 2024 10:09:20 +0800
From: Ethan Zhao <haifeng.zhao@...ux.intel.com>
To: Lukas Wunner <lukas@...ner.de>
Cc: bhelgaas@...gle.com, Smita.KoralahalliChannabasappa@....com,
 ilpo.jarvinen@...ux.intel.com, sathyanarayanan.kuppuswamy@...ux.intel.com,
 linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org, kbusch@...nel.org
Subject: Re: [PATCH pci-next] pci/edr: Ignore Surprise Down error on hot
 removal

On 3/4/2024 7:58 PM, Lukas Wunner wrote:
> On Mon, Mar 04, 2024 at 04:08:19AM -0500, Ethan Zhao wrote:
>> Per PCI firmware spec r3.3 sec 4.6.12, for firmware first mode DPC
>> handling path, FW should clear UC errors logged by port and bring link
>> out of DPC, but because of ambiguity of wording in the spec, some BIOSes
>> doesn't clear the surprise down error and the error bits in pci status,
>> still notify OS to handle it. thus following trick is needed in EDR when
>> double reporting (hot removal interrupt && dpc notification) is hit.
> Please provide more detailed information about the hardware and BIOS
> affected by this.
>
You know, to disclose the detail hardware and BIOS info list might invovle
very complex internal legal approval process.

To put it simply, at least one platform, such SPR and one customer's BIOS
is affected.

If FFM(firmware first mode) and hotplug are executed. the side effect can
be observed if it is affected, UC errors are reported along with pciehp
log.

>> -static void dpc_handle_surprise_removal(struct pci_dev *pdev)
>> +bool  dpc_handle_surprise_removal(struct pci_dev *pdev)
>>   {
>> +	if (!dpc_is_surprise_removal(pdev))
>> +		return false;
> This change of moving dpc_is_surprise_removal() into
> dpc_handle_surprise_removal() seems unrelated to the problem at hand.
>
> Please drop it if it's unnecessary to fix the issue.

To only export one function dpc_is_surprise_removal()... or I have to
export them both.
Seems I should keep them intact or refactor them in separated patch ?

>
>
>> --- a/drivers/pci/pcie/edr.c
>> +++ b/drivers/pci/pcie/edr.c
>> @@ -184,6 +184,9 @@ static void edr_handle_event(acpi_handle handle, u32 event, void *data)
>>   		goto send_ost;
>>   	}
>>   
>> +	if (dpc_handle_surprise_removal(edev))
>> +		goto send_ost;
>> +
>>   	dpc_process_error(edev);
>>   	pci_aer_raw_clear_status(edev);
> This seems to be the only necessary change.  Please reduce the
> patch to contain only it and no other refactoring.
>
> Please capitalize the "PCI/EDR: " prefix in the subject and add
> a Fixes tag.

Sure !

Thanks,
Ethan

> Thanks,
>
> Lukas