From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751824AbbJCHgm (ORCPT ); Sat, 3 Oct 2015 03:36:42 -0400 Received: from mga03.intel.com ([134.134.136.65]:49984 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751536AbbJCHgl (ORCPT ); Sat, 3 Oct 2015 03:36:41 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,627,1437462000"; d="scan'208";a="818461746" 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 To: Borislav Petkov References: <20150923085950.GA3440@pd.tnic> <20150923144450.GD3383@phenom.ffwll.local> <20150923160621.GA3446@pd.tnic> <20150923161839.GB3446@pd.tnic> <20150926164651.GA3640@pd.tnic> <560A50DC.1040505@linux.intel.com> <20150929105138.GA12037@nazgul.tnic> <560B9323.6000309@linux.intel.com> <20150930124432.GS3036@8bytes.org> <560C153C.10600@linux.intel.com> <20150930173619.GA3826@pd.tnic> Cc: Joerg Roedel , Daniel Vetter , Thomas Gleixner , Bjorn Helgaas , Alex Deucher , Alex Deucher , =?UTF-8?Q?Christian_K=c3=b6nig?= , Maling list - DRI developers , lkml From: Jiang Liu Organization: Intel Message-ID: <560F8583.2010403@linux.intel.com> Date: Sat, 3 Oct 2015 15:36:35 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20150930173619.GA3826@pd.tnic> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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); > } > -- >