linux-kernel - Re: [PATCH] PCI/DPC: Add pcie_ports=dpc-native parameter to bring back old behavior

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]

Date:   Thu, 7 Nov 2019 14:05:26 -0800
From:   Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>
To:     Olof Johansson <olof@...om.net>
Cc:     Bjorn Helgaas <helgaas@...nel.org>,
        Keith Busch <keith.busch@...el.com>, linux-pci@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] PCI/DPC: Add pcie_ports=dpc-native parameter to bring
 back old behavior


On 11/7/19 12:09 PM, Olof Johansson wrote:
> On Thu, Nov 7, 2019 at 12:02 PM Kuppuswamy Sathyanarayanan
> <sathyanarayanan.kuppuswamy@...ux.intel.com> wrote:
>> Hi,
>>
>> On 10/25/19 1:20 PM, Bjorn Helgaas wrote:
>>> On Wed, Oct 23, 2019 at 12:22:05PM -0700, Olof Johansson wrote:
>>>> In commit eed85ff4c0da7 ("PCI/DPC: Enable DPC only if AER is available"),
>>>> the behavior was changed such that native (kernel) handling of DPC
>>>> got tied to whether the kernel also handled AER. While this is what
>>>> the standard recommends, there are BIOSes out there that lack the DPC
>>>> handling since it was never required in the past.
>>> Some systems do not grant OS control of AER via _OSC.  I guess the
>>> problem is that on those systems, the OS DPC driver used to work, but
>>> after eed85ff4c0da7, it does not.  Right?
>> I need some clarification on this issue. Do you mean in these systems,
>> firmware expects OS to handle DPC and AER, but it does not let OS know
>> about it via _OSC ?
> The OS and BIOS both assumed behavior as before eed85ff4c0da7 -- AER
> handled by firmware but DPC handled by kernel.
>
> I.e. a classic case of "Sure, the spec says this, but in reality
> implementations relied on actual behavior", and someone had a
> regression and need a way to restore previous behavior.

Got it. I don't know whether its good to add hacks to support products 
that does not follow spec.
But, do you think it would be useful to add some kind of warning message 
when this option is
enabled ? May be it could be useful in debugging.

>
> -Olof
>
-- 
Sathyanarayanan Kuppuswamy
Linux kernel developer