linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiang Liu <jiang.liu@linux.intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Joerg Roedel" <joro@8bytes.org>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Alex Deucher" <alexdeucher@gmail.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Maling list - DRI developers" <dri-devel@lists.freedesktop.org>,
	lkml <linux-kernel@vger.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
Date: Sat, 3 Oct 2015 15:36:35 +0800	[thread overview]
Message-ID: <560F8583.2010403@linux.intel.com> (raw)
In-Reply-To: <20150930173619.GA3826@pd.tnic>



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);
>  }
> --
> 

  parent reply	other threads:[~2015-10-03  7:36 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-21 13:31 WARNING: CPU: 4 PID: 863 at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x88/0x90() Borislav Petkov
2015-09-22 19:06 ` Borislav Petkov
2015-09-22 19:58 ` Alex Deucher
2015-09-22 20:21   ` Borislav Petkov
2015-09-22 20:54     ` Alex Deucher
2015-09-23  7:25       ` Daniel Vetter
2015-09-23  8:59         ` Borislav Petkov
2015-09-23 14:44           ` Daniel Vetter
2015-09-23 16:06             ` Borislav Petkov
2015-09-23 16:18               ` Borislav Petkov
2015-09-26 16:46                 ` WARNING: CPU: 4 PID: 863 at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x88/0x90() - evildoer found and neutralized Borislav Petkov
2015-09-29  8:50                   ` Jiang Liu
2015-09-29 10:51                     ` Borislav Petkov
2015-09-30  7:45                       ` Jiang Liu
2015-09-30 12:44                         ` Joerg Roedel
2015-09-30 17:00                           ` Jiang Liu
2015-09-30 17:36                             ` Borislav Petkov
2015-09-30 18:07                               ` Joerg Roedel
2015-10-03  7:36                               ` Jiang Liu [this message]
2015-10-03  9:35                                 ` Borislav Petkov
2015-10-05 10:03                                 ` Joerg Roedel
2015-10-06 13:13                                   ` Jiang Liu
2015-10-09 10:24                                     ` Joerg Roedel
2015-09-30 18:06                             ` Joerg Roedel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=560F8583.2010403@linux.intel.com \
    --to=jiang.liu@linux.intel.com \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=bhelgaas@google.com \
    --cc=bp@alien8.de \
    --cc=christian.koenig@amd.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=joro@8bytes.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).