From patchwork Wed May 22 09:43:02 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matt Fleming X-Patchwork-Id: 2601221 X-Patchwork-Delegate: bhelgaas@google.com Return-Path: X-Original-To: patchwork-linux-pci@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id A3AC63FD2B for ; Wed, 22 May 2013 09:52:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753501Ab3EVJwl (ORCPT ); Wed, 22 May 2013 05:52:41 -0400 Received: from arkanian.console-pimps.org ([212.110.184.194]:58281 "EHLO arkanian.console-pimps.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753447Ab3EVJwk (ORCPT ); Wed, 22 May 2013 05:52:40 -0400 X-Greylist: delayed 569 seconds by postgrey-1.27 at vger.kernel.org; Wed, 22 May 2013 05:52:40 EDT Received: by arkanian.console-pimps.org (Postfix, from userid 1002) id 9F8C66C06E; Wed, 22 May 2013 10:43:10 +0100 (BST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on arkanian.vm.bytemark.co.uk X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 Received: from localhost (97e06d5a.skybroadband.com [151.224.109.90]) by arkanian.console-pimps.org (Postfix) with ESMTPSA id 980C76C050; Wed, 22 May 2013 10:43:04 +0100 (BST) From: Matt Fleming To: Bjorn Helgaas Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, Matt Fleming , Matthew Garrett , Seth Forshee , Jesse Barnes , Subject: [PATCH] x86/PCI: setup data may be in highmem Date: Wed, 22 May 2013 10:43:02 +0100 Message-Id: <1369215782-32697-1-git-send-email-matt@console-pimps.org> X-Mailer: git-send-email 1.8.1.4 Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org From: Matt Fleming pcibios_add_device() assumes that the physical addresses stored in setup_data are accessible via the direct kernel mapping, and that calling phys_to_virt() is valid. This isn't guaranteed to be true on x86 where the direct mapping range is much smaller than on x86-64. Calling phys_to_virt() on a highmem address results in the following, BUG: unable to handle kernel paging request at 39a3c198 IP: [] pcibios_add_device+0x2f/0x90 *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: Pid: 1, comm: swapper/0 Tainted: G W I 3.9.0-rc2+ #280 EIP: 0060:[] EFLAGS: 00010206 CPU: 1 EIP is at pcibios_add_device+0x2f/0x90 EAX: f6258800 EBX: f6258800 ECX: 79a3c190 EDX: 39a3c190 ESI: f62d9814 EDI: f6258864 EBP: f60add38 ESP: f60add2c DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 CR0: 8005003b CR2: 39a3c198 CR3: 02b91000 CR4: 001007d0 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process swapper/0 (pid: 1, ti=f60ac000 task=f60b0000 task.ti=f60ac000) Stack: f6258800 f62d9814 f6258864 f60add4c c2370c73 00000000 f62d9800 00000000 f60add6c c274640b 0000ea60 f6258800 0f008086 f62d9800 f62d9800 00000000 f60add84 c2370d08 00000000 00000008 f62d9800 00000000 f60adda4 c2371904 Call Trace: [] pci_device_add+0xe3/0x130 [] pci_scan_single_device+0x8b/0xb0 [] pci_scan_slot+0x48/0x100 [] pci_scan_child_bus+0x24/0xc0 [] pci_acpi_scan_root+0x2c0/0x490 [] acpi_pci_root_add+0x312/0x42f [] ? acpi_device_notify_fixed+0x1d/0x1d [] acpi_bus_device_attach+0x77/0xdd [] acpi_ns_walk_namespace+0xb1/0x163 [] ? acpi_bus_type_and_status+0x82/0x82 [] acpi_walk_namespace+0x7e/0xa8 [] ? acpi_bus_type_and_status+0x82/0x82 [] acpi_bus_scan+0x9a/0xa6 [] ? acpi_bus_type_and_status+0x82/0x82 [] acpi_scan_init+0x51/0x144 [] ? pci_mmcfg_late_init+0x49/0x4b [] acpi_init+0x224/0x28c [] do_one_initcall+0x34/0x170 [] ? acpi_sleep_proc_init+0x2e/0x2e [] kernel_init_freeable+0x119/0x1b6 [] ? do_early_param+0x74/0x74 [] kernel_init+0x10/0xd0 [] ret_from_kernel_thread+0x1b/0x28 [] ? rest_init+0x60/0x60 The most reliable way to trigger this crash seems to be booting a 32-bit kernel via the EFI boot stub. The solution is to use early_ioremap() instead of phys_to_virt() to map the setup data into the kernel address space. Tested-by: Jani Nikula Cc: Matthew Garrett Cc: Bjorn Helgaas Cc: Seth Forshee Cc: Jesse Barnes Cc: Signed-off-by: Matt Fleming --- arch/x86/pci/common.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c index 305c68b..7ae6671 100644 --- a/arch/x86/pci/common.c +++ b/arch/x86/pci/common.c @@ -628,7 +628,7 @@ int pcibios_add_device(struct pci_dev *dev) pa_data = boot_params.hdr.setup_data; while (pa_data) { - data = phys_to_virt(pa_data); + data = early_ioremap(pa_data, sizeof(*rom)); if (data->type == SETUP_PCI) { rom = (struct pci_setup_rom *)data; @@ -645,6 +645,7 @@ int pcibios_add_device(struct pci_dev *dev) } } pa_data = data->next; + early_iounmap(data, sizeof(*rom)); } return 0; }