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]
Date: Wed, 6 Mar 2024 09:37:01 +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/5/2024 5:21 PM, Lukas Wunner wrote:
> On Tue, Mar 05, 2024 at 10:09:20AM +0800, Ethan Zhao wrote:
>> On 3/4/2024 7:58 PM, Lukas Wunner wrote:
>>> On Mon, Mar 04, 2024 at 04:08:19AM -0500, Ethan Zhao wrote:
>>>> -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 ?
> Please keep them intact and make both public.  (You're not "exporting"
> the functions, there are no modular users.)
>
> However, I doubt whether you need to respin this patch at all:
>
>
>> Reproduced on "Hardware name: Intel Corporation ArcherCity/ArcherCity,
>>   BIOS EGSDCRB1.86B.0107.D20.2310211929 10/21/2023"
> Eagle Stream BIOS, isn't that an Intel-provided BIOS?
>
> Sathya's comments sound like the BIOS is misbehaving.  If so,
> then the first thing to do is ask the BIOS team to fix the issue.
> We do not want to pollute the kernel with workarounds for BIOS bugs
> that can be fixed in the field through a BIOS update.

Agree, BIOS writer finally was convinced to fix it in BIOS.
no need to respin.


Thanks,
Ethan

>
> Thanks,
>
> Lukas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ