Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751314AbbEZAmu (ORCPT ); Mon, 25 May 2015 20:42:50 -0400 Received: from v094114.home.net.pl ([79.96.170.134]:64629 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751037AbbEZAmt (ORCPT ); Mon, 25 May 2015 20:42:49 -0400 From: "Rafael J. Wysocki" To: Boris Ostrovsky , Sander Eikelenboom Cc: david.vrabel@citrix.com, xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Subject: Re: [Xen-devel] Regression due to "device property: Make it possible to use secondary firmware nodes" Re: Xen-unstable + linux 4.1-mergewindow: problems with PV guest pci passthrough: pcifront pci-0: pciback not responding!!! Date: Tue, 26 May 2015 03:08:17 +0200 Message-ID: <1901357.YAorP09rCo@vostro.rjw.lan> User-Agent: KMail/4.11.5 (Linux/4.0.0+; KDE/4.11.5; x86_64; ; ) In-Reply-To: <2059136.yfbqz351P1@vostro.rjw.lan> References: <555FDDA1.8030806@oracle.com> <1768370.Rs1vKzEP4D@vostro.rjw.lan> <2059136.yfbqz351P1@vostro.rjw.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2697 Lines: 71 On Tuesday, May 26, 2015 01:42:16 AM Rafael J. Wysocki wrote: > On Tuesday, May 26, 2015 01:22:12 AM Rafael J. Wysocki wrote: > > On Friday, May 22, 2015 09:53:37 PM Boris Ostrovsky wrote: > > > On 05/22/2015 04:11 AM, Sander Eikelenboom wrote: > > > > Hello Sander, > > > > > > [cut] > > > > (+Rafael again) > > > > > > So the immediate cause of those errors is that pdev->evtchn is 0. > > > Backend is not notified and things not go well then. > > > > > > And it is indeed caused by 97badf873ab60e841243b66133ff9eff2a46ef29: > > > > > > We allocate pcifront_sd in pcifront_scan_root() and then pass it to > > > pci_scan_bus_parented() as sysdata. Eventually this sysdata is used in > > > pcibios_root_bridge_prepare() as pci_sysdata. It is dereferenced as > > > pci_sysdata->companion (which I believe is aliased to pcifront_sd->pdev) > > Well, there is an int node field between them, so I'm not sure. > > > > and then set_primary_fwnode() writes it, thus corrupting > > > pcifront_sd->pdev (and I think this is what sets evtchn to zero). > > So the corruption happens when set_primary_fwnode() writes NULL to the > 'secondary' field of object pointed to by 'fwnode'. > > This isn't strictly necessary and we might avoid the crash by only > writing to fwnode->secondary if fn is not NULL. > > So, Sander please test the patch below too if possible. > > Of course, that doesn't solve a problem of passing an incorrect pointer > to ACPI_COMPANION_SET() in pcibios_root_bridge_prepare(). And here's one more thing to test. Please let me know (a) if you get the stack trace from the WARN_ON() in the patch below and (b) whether or not things work again with this patch applied. --- arch/x86/pci/acpi.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) Index: linux-pm/arch/x86/pci/acpi.c =================================================================== --- linux-pm.orig/arch/x86/pci/acpi.c +++ linux-pm/arch/x86/pci/acpi.c @@ -483,8 +483,12 @@ struct pci_bus *pci_acpi_scan_root(struc int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge) { struct pci_sysdata *sd = bridge->bus->sysdata; + struct acpi_device *companion = sd->companion; + + /* Protect against passing pointers of an incorrect type via sysdata. */ + if (!WARN_ON(companion && companion->fwnode.type != FWNODE_ACPI)) + ACPI_COMPANION_SET(&bridge->dev, companion); - ACPI_COMPANION_SET(&bridge->dev, sd->companion); return 0; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/