| 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
| ||
|
Message-ID: <d47e5af3-d339-01b6-5925-a2037b177be2@linux.alibaba.com>
Date: Thu, 13 Jan 2022 15:34:41 +0800
From: Yao Hongbo <yaohongbo@...ux.alibaba.com>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: bhelgaas@...gle.com, lukas@...ner.de,
zhangliguang@...ux.alibaba.com,
alikernel-developer@...ux.alibaba.com, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org,
"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [RFC PATCH v2] PCI: Waiting command completed in
get_port_device_capability()
在 2022/1/13 上午2:01, Bjorn Helgaas 写道:
> On Wed, Jan 12, 2022 at 03:33:25PM +0800, Yao Hongbo wrote:
>>
>>
>> 在 2022/1/12 上午2:55, Bjorn Helgaas 写道:
>>> [+cc Lukas, Rafael (in case you have any recollection of 2bd50dd800b5)]
>>>
>>> On Fri, Jan 07, 2022 at 11:22:49AM +0800, Yao Hongbo wrote:
>>>> According to the PCIe specification Revision 5.0, section
>>>> 7.5.3.11 (slot Status Register), if Command Complete notification
>>>> is supported, a write to the slot control register needs to set
>>>> the command completed bit, which can indicate the controller is
>>>> ready to receive the next command.
>>>>
>>>> However, before probing the pcie hotplug service, there needs to set
>>>> HPIE bit in the slot ctrl register to disable hotplug interrupts,
>>>> and there is no wait currently.
>>>>
>>>> The interval between the two functions get_port_device_capability() and
>>>> pcie_disable_notification() is not long, which may cause the latter to
>>>> be interfered by the former.
>>>>
>>>> The command complete event received by pcie_disable_notification() may
>>>> belong to the operation of get_port_device_capability().
>>>
>>> Yes, looks like a potential problem.
>>>
>>>> Signed-off-by: Liguang Zhang <zhangliguang@...ux.alibaba.com>
>>>> Signed-off-by: Yao Hongbo <yaohongbo@...ux.alibaba.com>
>>>> ---
>>>> drivers/pci/pcie/portdrv_core.c | 40 ++++++++++++++++++++++++++++++++++++++--
>>>> 1 file changed, 38 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
>>>> index bda6308..ec2088b6e 100644
>>>> --- a/drivers/pci/pcie/portdrv_core.c
>>>> +++ b/drivers/pci/pcie/portdrv_core.c
>>>> @@ -15,6 +15,7 @@
>>>> #include <linux/string.h>
>>>> #include <linux/slab.h>
>>>> #include <linux/aer.h>
>>>> +#include <linux/delay.h>
>>>>
>>>> #include "../pci.h"
>>>> #include "portdrv.h"
>>>> @@ -190,6 +191,42 @@ static int pcie_init_service_irqs(struct pci_dev *dev, int *irqs, int mask)
>>>> return 0;
>>>> }
>>>>
>>>> +static void pcie_port_disable_hp_interrupt(struct pci_dev *dev)
>>>> +{
>>>> + u16 slot_status;
>>>> + u32 slot_cap;
>>>> + int timeout = 1000;
>>>> +
>>>> + pcie_capability_clear_word(dev, PCI_EXP_SLTCTL,
>>>> + PCI_EXP_SLTCTL_CCIE | PCI_EXP_SLTCTL_HPIE);
>>>> +
>>>> + /*
>>>> + * If the command completed notification is not supported,
>>>> + * we don't need to wait after writing to the slot ctrl register.
>>>> + */
>>>> + pcie_capability_read_dword(dev, PCI_EXP_SLTCAP, &slot_cap);
>>>> + if (slot_cap & PCI_EXP_SLTCAP_NCCS)
>>>> + return;
>>>> +
>>>> + do {
>>>> + pcie_capability_read_word(dev, PCI_EXP_SLTSTA, &slot_status);
>>>> + if (slot_status == (u16) ~0) {
>>>> + pci_info(dev, "%s: no response from device\n", __func__);
>>>> + return;
>>>> + }
>>>> +
>>>> + if (slot_status & PCI_EXP_SLTSTA_CC) {
>>>> + pcie_capability_write_word(dev, PCI_EXP_SLTSTA, PCI_EXP_SLTSTA_CC);
>>>> + return;
>>>> + }
>>>> +
>>>> + msleep(10);
>>>> + timeout -= 10;
>>>> + } while (timeout >= 0);
>>>> +
>>>> + pci_info(dev, "Timeout on hotplug disable interrupt!\n");
>>>> +}
>>>> +
>>>> /**
>>>> * get_port_device_capability - discover capabilities of a PCI Express port
>>>> * @dev: PCI Express port to examine
>>>> @@ -213,8 +250,7 @@ static int get_port_device_capability(struct pci_dev *dev)
>>>> * Disable hot-plug interrupts in case they have been enabled
>>>> * by the BIOS and the hot-plug service driver is not loaded.
>>>> */
>>>> - pcie_capability_clear_word(dev, PCI_EXP_SLTCTL,
>>>> - PCI_EXP_SLTCTL_CCIE | PCI_EXP_SLTCTL_HPIE);
>>>> + pcie_port_disable_hp_interrupt(dev);
>>>
>>> This originally came from 2bd50dd800b5 ("PCI: PCIe: Disable PCIe port
>>> services during port initialization"), where we disable hotplug
>>> interrupts in case the hotplug driver is not available.
>>>
>>> In general, I think the OS should not be responsible for disabling
>>> interrupts for feature X. The OS may predate feature X and may not
>>> know anything about X at all. The power-on default for interrupts
>>> related to X should be "disabled" (as it is for HPIE and CCIE), and if
>>> firmware enables them, it should disable them or arrange to handle
>>> them itself before handing off to the OS.
>>>
>>> I don't know whether 2bd50dd800b5 was prompted by spurious hotplug
>>> interrupts or not. If it was, I think we were seeing a firmware
>>> defect or possibly a pciehp initialization issue.
>>>
>>> At the time of 2bd50dd800b5, we always cleared HPIE and CCIE here.
>>>
>>> But now, on ACPI systems, we only clear HPIE and CCIE here if we *do*
>>> have the hotplug driver (because host->native_pcie_hotplug only
>>> remains set if we have been granted control via _OSC, and we only
>>> request control when CONFIG_HOTPLUG_PCI_PCIE is enabled). On these
>>> systems, we should be able to remove this disable code because pciehp
>>> will do whatever it needs.
>>>
>>> For non-ACPI systems, bridge->native_pcie_hotplug will always be set,
>>> so we will clear HPIE and CCIE here and then (if
>>> CONFIG_HOTPLUG_PCI_PCIE is enabled) initialize pciehp soon after,
>>> which may be a problem as you describe.
>>>
>>> What kind of system are you seeing the problem on? It seems like it
>>> should be safe to drop the HPIE and CCIE disable here for ACPI
>>> systems. And *likely* we could do the same for non-ACPI systems,
>>> though I have no experience there.
>>
>> Hi, Bjorn
>> Thanks for your comments.
>>
>> The problem occurs on ACPI systems.
>>
>> acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
>> acpi PNP0A08:00: _OSC: platform does not support [SHPCHotplug AER LTR DPC]
>> acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME PCIeCapability]
>>
>> We clear HPIE and CCIE here because the firmware doesn't control
>> Hotplug via __OSC.
>>
>> And on ACPI systems, we can also set pcie_ports=native, which will
>> also encounter such problems.
>
> What happens if you just drop that call like the patch below?
>
> If that avoids the problem, then we can talk about whether we need to
> worry about broken firmware in the non-ACPI or "pcie_ports=native"
> cases.
Hi, Bjorn.
This can avoid the problem currently.
But i'm not sure if removing this code will introduce other problems,
such as suprious hotplug before probing hotplug service.
Thanks,
Hongbo.
> diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
> index bda630889f95..76a3bd237bf9 100644
> --- a/drivers/pci/pcie/portdrv_core.c
> +++ b/drivers/pci/pcie/portdrv_core.c
> @@ -208,13 +208,6 @@ static int get_port_device_capability(struct pci_dev *dev)
> if (dev->is_hotplug_bridge &&
> (pcie_ports_native || host->native_pcie_hotplug)) {
> services |= PCIE_PORT_SERVICE_HP;
> -
> - /*
> - * Disable hot-plug interrupts in case they have been enabled
> - * by the BIOS and the hot-plug service driver is not loaded.
> - */
> - pcie_capability_clear_word(dev, PCI_EXP_SLTCTL,
> - PCI_EXP_SLTCTL_CCIE | PCI_EXP_SLTCTL_HPIE);
> }
>
> #ifdef CONFIG_PCIEAER
Powered by blists - more mailing lists