From patchwork Thu Feb 11 21:10:26 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Konrad Rzeszutek Wilk X-Patchwork-Id: 8284961 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id EBD899F38B for ; Thu, 11 Feb 2016 21:13:21 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 118EF20397 for ; Thu, 11 Feb 2016 21:13:21 +0000 (UTC) Received: from lists.xen.org (lists.xenproject.org [50.57.142.19]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1D30D202EC for ; Thu, 11 Feb 2016 21:13:20 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aTyVe-0006ir-2j; Thu, 11 Feb 2016 21:10:42 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aTyVd-0006im-9a for xen-devel@lists.xenproject.org; Thu, 11 Feb 2016 21:10:41 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id B6/9A-02745-0D8FCB65; Thu, 11 Feb 2016 21:10:40 +0000 X-Env-Sender: konrad@char.us.oracle.com X-Msg-Ref: server-12.tower-31.messagelabs.com!1455225038!21788373!1 X-Originating-IP: [156.151.31.81] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTU2LjE1MS4zMS44MSA9PiAyODgzMzk=\n X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 63230 invoked from network); 11 Feb 2016 21:10:39 -0000 Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by server-12.tower-31.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 11 Feb 2016 21:10:39 -0000 Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1BLAZDr027002 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Feb 2016 21:10:35 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u1BLAZ2M009551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2016 21:10:35 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1BLAYIR032743; Thu, 11 Feb 2016 21:10:35 GMT Received: from char.us.oracle.com (/10.137.176.158) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Feb 2016 13:10:34 -0800 Received: by char.us.oracle.com (Postfix, from userid 1000) id 8B4BF6A4BF1; Thu, 11 Feb 2016 16:10:33 -0500 (EST) From: Konrad Rzeszutek Wilk To: Tommi Airikka , linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, david.vrabel@citrix.com, boris.ostrovsky@oracle.com Date: Thu, 11 Feb 2016 16:10:26 -0500 Message-Id: <1455225026-25792-5-git-send-email-konrad.wilk@oracle.com> X-Mailer: git-send-email 2.1.0 In-Reply-To: <1455225026-25792-1-git-send-email-konrad.wilk@oracle.com> References: <1455225026-25792-1-git-send-email-konrad.wilk@oracle.com> X-Source-IP: userv0022.oracle.com [156.151.31.74] Cc: stable@vger.kernel.org, Konrad Rzeszutek Wilk Subject: [Xen-devel] [PATCH 4/4] xen/pcifront: Fix mysterious crashes when NUMA locality information was extracted. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Occasionaly PV guests would crash with: pciback 0000:00:00.1: Xen PCI mapped GSI0 to IRQ16 BUG: unable to handle kernel paging request at 0000000d1a8c0be0 .. snip.. ] find_next_bit+0xb/0x10 [] cpumask_next_and+0x22/0x40 [] pci_device_probe+0xb8/0x120 [] ? driver_sysfs_add+0x77/0xa0 [] driver_probe_device+0x1a4/0x2d0 [] ? pci_match_device+0xdd/0x110 [] __device_attach_driver+0xa7/0xb0 [] ? __driver_attach+0xa0/0xa0 [] bus_for_each_drv+0x62/0x90 [] __device_attach+0xbd/0x110 [] device_attach+0xb/0x10 [] pci_bus_add_device+0x3c/0x70 [] pci_bus_add_devices+0x38/0x80 [] pcifront_scan_root+0x13e/0x1a0 [] pcifront_backend_changed+0x262/0x60b [] ? xenbus_gather+0xd6/0x160 [] ? put_object+0x2f/0x50 [] xenbus_otherend_changed+0x9d/0xa0 [] backend_changed+0xe/0x10 [] xenwatch_thread+0xc8/0x190 [] ? woken_wake_function+0x10/0x10 which was the result of two things: When we call pci_scan_root_bus we would pass in 'sd' (sysdata) pointer which was an 'pcifront_sd' structure. However in the pci_device_add it expects that the 'sd' is 'struct sysdata' and sets the dev->node to what is in sd->node (offset 4): set_dev_node(&dev->dev, pcibus_to_node(bus)); __pcibus_to_node(const struct pci_bus *bus) { const struct pci_sysdata *sd = bus->sysdata; return sd->node; } However our structure was pcifront_sd which had nothing at that offset: struct pcifront_sd { int domain; /* 0 4 */ /* XXX 4 bytes hole, try to pack */ struct pcifront_device * pdev; /* 8 8 */ } That is an hole - filled with garbage as we used kmalloc instead of kzalloc (the second problem). This patch fixes the issue by: 1) Use kzalloc to initialize to a well known state. 2) Put 'struct pci_sysdata' at the start of 'pcifront_sd'. That way access to the 'node' will access the right offset. CC: stable@vger.kernel.org Signed-off-by: Konrad Rzeszutek Wilk Reviewed-by: Boris Ostrovsky --- drivers/pci/xen-pcifront.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c index c777b97..66d197d 100644 --- a/drivers/pci/xen-pcifront.c +++ b/drivers/pci/xen-pcifront.c @@ -53,7 +53,7 @@ struct pcifront_device { }; struct pcifront_sd { - int domain; + struct pci_sysdata sd; struct pcifront_device *pdev; }; @@ -67,7 +67,9 @@ static inline void pcifront_init_sd(struct pcifront_sd *sd, unsigned int domain, unsigned int bus, struct pcifront_device *pdev) { - sd->domain = domain; + /* Because we do not expose that information via XenBus. */ + sd->sd.node = first_online_node; + sd->sd.domain = domain; sd->pdev = pdev; } @@ -468,8 +470,8 @@ static int pcifront_scan_root(struct pcifront_device *pdev, dev_info(&pdev->xdev->dev, "Creating PCI Frontend Bus %04x:%02x\n", domain, bus); - bus_entry = kmalloc(sizeof(*bus_entry), GFP_KERNEL); - sd = kmalloc(sizeof(*sd), GFP_KERNEL); + bus_entry = kzalloc(sizeof(*bus_entry), GFP_KERNEL); + sd = kzalloc(sizeof(*sd), GFP_KERNEL); if (!bus_entry || !sd) { err = -ENOMEM; goto err_out; @@ -576,6 +578,7 @@ static void pcifront_free_roots(struct pcifront_device *pdev) free_root_bus_devs(bus_entry->bus); kfree(bus_entry->bus->sysdata); + bus_entry->bus->sysdata = NULL; device_unregister(bus_entry->bus->bridge); pci_remove_bus(bus_entry->bus);