Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751291AbbEYXQt (ORCPT ); Mon, 25 May 2015 19:16:49 -0400 Received: from v094114.home.net.pl ([79.96.170.134]:65350 "HELO v094114.home.net.pl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751142AbbEYXQs (ORCPT ); Mon, 25 May 2015 19:16:48 -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 01:42:16 +0200 Message-ID: <2059136.yfbqz351P1@vostro.rjw.lan> User-Agent: KMail/4.11.5 (Linux/4.0.0+; KDE/4.11.5; x86_64; ; ) In-Reply-To: <1768370.Rs1vKzEP4D@vostro.rjw.lan> References: <555FDDA1.8030806@oracle.com> <1768370.Rs1vKzEP4D@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: 2153 Lines: 61 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(). --- drivers/base/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Index: linux-pm/drivers/base/core.c =================================================================== --- linux-pm.orig/drivers/base/core.c +++ linux-pm/drivers/base/core.c @@ -2167,7 +2167,9 @@ void set_primary_fwnode(struct device *d if (fwnode_is_primary(fn)) fn = fn->secondary; - fwnode->secondary = fn; + if (fn) + fwnode->secondary = fn; + dev->fwnode = fwnode; } else { dev->fwnode = fwnode_is_primary(dev->fwnode) ? -- 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/