linux-kernel - Re: WARNING: CPU: 4 PID: 863 at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x88/0x90()

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:	Sat, 3 Oct 2015 15:36:35 +0800
From:	Jiang Liu <jiang.liu@...ux.intel.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Joerg Roedel <joro@...tes.org>, Daniel Vetter <daniel@...ll.ch>,
	Thomas Gleixner <tglx@...utronix.de>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Alex Deucher <alexdeucher@...il.com>,
	Alex Deucher <alexander.deucher@....com>,
	Christian König <christian.koenig@....com>,
	Maling list - DRI developers 
	<dri-devel@...ts.freedesktop.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: WARNING: CPU: 4 PID: 863 at include/drm/drm_crtc.h:1577
 drm_helper_choose_encoder_dpms+0x88/0x90() - evildoer found and neutralized



On 2015/10/1 1:36, Borislav Petkov wrote:
> On Thu, Oct 01, 2015 at 01:00:44AM +0800, Jiang Liu wrote:
>> Thanks Joerg, that makes sense. If some driver tries to binding to
>> the IOMMU device, it will trigger the scenario as you described. For
>> example, Xen backend driver will try to probe all PCI devices if
>> enabled. I will do more investigation tomorrow.
> 
> Right, so this fixes the issue on my box, courtesy of Joerg. WE
> basically don't disable the IRQ on MSI-enabled devices. The AMD IOMMU
> uses a barebones PCI device but not a PCI driver, which would be an
> overkill.
> 
> ---
> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
> index 09d3afc..29ec2eb 100644
> --- a/arch/x86/pci/common.c
> +++ b/arch/x86/pci/common.c
> @@ -674,12 +674,15 @@ int pcibios_add_device(struct pci_dev *dev)
>  
>  int pcibios_alloc_irq(struct pci_dev *dev)
>  {
> +	if (pci_dev_msi_enabled(dev))
> +		return 0;
We may return -EBUSY here to reject the probe operation. It
doesn't make sense to continue the probe if MSI is already enabled,
tt also helps to avoid calling pcibios_free_irq() in function
pci_device_probe().

> +
>  	return pcibios_enable_irq(dev);
>  }
>  
>  void pcibios_free_irq(struct pci_dev *dev)
>  {
> -	if (pcibios_disable_irq)
> +	if (!pci_dev_msi_enabled(dev) && pcibios_disable_irq)
The above change is not needed, pcibios_disable_irq() will
first check !pci_has_managed_irq(dev) before actually freeing
PCI irq. pci_has_managed_irq(dev) only returns true if
pcibios_alloc_irq() succeeds.

So to summary, I think we only need following change to fix the
regression:
 int pcibios_alloc_irq(struct pci_dev *dev)
 {
+	if (pci_dev_msi_enabled(dev))
+		return -EBUSY;

What do you think?
Thanks!
Gerry

>  		pcibios_disable_irq(dev);
>  }
> --
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/