Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp254203imm; Tue, 5 Jun 2018 19:14:11 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJscOHcTQm133FDfgMlgXdQuemhi8wW7TYt+APXWkWE6DUKZH3Tm3Gap10kGIy8zjCCzBh8 X-Received: by 2002:a62:2f44:: with SMTP id v65-v6mr485651pfv.83.1528251251146; Tue, 05 Jun 2018 19:14:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528251251; cv=none; d=google.com; s=arc-20160816; b=n3fhY5qJURRuZRiar/oADRQKDU77lCPlsNeoOXqIWQYVG+zxBJ8Pv7+dzIbH/apjGv OXetTZkYJiLfIlG/MAQ+VuM9hAqGKEeKYO+tu0cMJUD70ycDv70/awk2LWCg4X8aJcOX U9S5oAqskKHcVIwTBP9nHZKyiAFBSwghY7506StBclD1G0aEB/5rKZ8bGzHac6UHgBeU +FXvxuJhEG+1gd3pdYic41QC7b1SRMzB/AdBffSSimc+abTJ7iwsCppTH4cKZA14I/CA 2gEWI/a5PHqpRgepoP0eIhtC0wTrH/ykC+Eq3NM+01dd+AnrQhBr9owbKZt4e2iY4TZU Di1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject:arc-authentication-results; bh=lHLlHl9OI2Kf+iuT3tLZcjb7AKo+AjYUdkE1myXlSJw=; b=QYsAW03/bUagDPGiY7sc5fDUbdWQ9MyxYnHC7MfEflMFUJteHTtxQ0mWSQerNeaql5 JwWKIM4K37l9hsn9YYyyCahvNiWaSD30YonKhopfS1CDhrFdz7xMwomQGsbU0ecQyClr 1aXFrjZTpTC2vZKms8Ck15w3FRIGvJiBbdtH0gL0ErQiIfj8u2zIx+clODVz3zZdsnwR GV0Zbnx1nNjVCKV/MGXH3BsguaUVjhWCN90FbbCx0PmjIxheST4uOEjaAyVtIZRLSUq+ GnJ755SBe+0/qM9pk+R3QFkQtMFAjWUWBql+1eeagEEBWYskQCi8pBM3zQhzstIWiC5W taWg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 31-v6si12991641pli.45.2018.06.05.19.13.54; Tue, 05 Jun 2018 19:14:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752762AbeFFCN0 (ORCPT + 99 others); Tue, 5 Jun 2018 22:13:26 -0400 Received: from szxga06-in.huawei.com ([45.249.212.32]:43437 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751977AbeFFCNZ (ORCPT ); Tue, 5 Jun 2018 22:13:25 -0400 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id ECAC62D4ED50A; Wed, 6 Jun 2018 10:13:21 +0800 (CST) Received: from [127.0.0.1] (10.177.29.40) by DGGEMS411-HUB.china.huawei.com (10.3.19.211) with Microsoft SMTP Server id 14.3.382.0; Wed, 6 Jun 2018 10:13:16 +0800 Subject: Re: [PATCH v3 1/2] PCI: Avoid panic when PCI IO resource's size is not page aligned To: Bjorn Helgaas References: <1527596299-57567-1-git-send-email-xieyisheng1@huawei.com> <20180605235303.GE226399@bhelgaas-glaptop.roam.corp.google.com> CC: , , , , , , , , , , From: Yisheng Xie Message-ID: Date: Wed, 6 Jun 2018 10:11:01 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20180605235303.GE226399@bhelgaas-glaptop.roam.corp.google.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.29.40] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Bjorn, On 2018/6/6 7:53, Bjorn Helgaas wrote: > On Tue, May 29, 2018 at 08:18:18PM +0800, Yisheng Xie wrote: >> Zhou reported a bug on Hisilicon arm64 D06 platform with 64KB page size: >> >> [ 2.470908] kernel BUG at lib/ioremap.c:72! >> [ 2.475079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP >> [ 2.480551] Modules linked in: >> [ 2.483594] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc7-00062-g0b41260-dirty #23 >> [ 2.491756] Hardware name: Huawei D06/D06, BIOS Hisilicon D06 UEFI Nemo 2.0 RC0 - B120 03/23/2018 >> [ 2.500614] pstate: 80c00009 (Nzcv daif +PAN +UAO) >> [ 2.505395] pc : ioremap_page_range+0x268/0x36c >> [ 2.509912] lr : pci_remap_iospace+0xe4/0x100 >> [...] >> [ 2.603733] Call trace: >> [ 2.606168] ioremap_page_range+0x268/0x36c >> [ 2.610337] pci_remap_iospace+0xe4/0x100 >> [ 2.614334] acpi_pci_probe_root_resources+0x1d4/0x214 >> [ 2.619460] pci_acpi_root_prepare_resources+0x18/0xa8 >> [ 2.624585] acpi_pci_root_create+0x98/0x214 >> [ 2.628843] pci_acpi_scan_root+0x124/0x20c >> [ 2.633013] acpi_pci_root_add+0x224/0x494 >> [ 2.637096] acpi_bus_attach+0xf8/0x200 >> [ 2.640918] acpi_bus_attach+0x98/0x200 >> [ 2.644740] acpi_bus_attach+0x98/0x200 >> [ 2.648562] acpi_bus_scan+0x48/0x9c >> [ 2.652125] acpi_scan_init+0x104/0x268 >> [ 2.655948] acpi_init+0x308/0x374 >> [ 2.659337] do_one_initcall+0x48/0x14c >> [ 2.663160] kernel_init_freeable+0x19c/0x250 >> [ 2.667504] kernel_init+0x10/0x100 >> [ 2.670979] ret_from_fork+0x10/0x18 >> >> The cause is the size of PCI IO resource is 32KB, which is 4K aligned but >> not 64KB aligned, however, ioremap_page_range() request the range as page >> aligned or it will trigger a BUG_ON() on ioremap_pte_range() it calls, as >> ioremap_pte_range increase the addr by PAGE_SIZE, which makes addr != end >> until trigger BUG_ON, if its incoming end is not page aligned. More detail >> trace is as following: >> >> ioremap_page_range >> -> ioremap_p4d_range >> -> ioremap_p4d_range >> -> ioremap_pud_range >> -> ioremap_pmd_range >> -> ioremap_pte_range >> >> This patch avoid panic by return -EINVAL if vaddr or resource size is not >> page aligned. >> >> Reported-by: Zhou Wang >> Tested-by: Xiaojun Tan >> Signed-off-by: Yisheng Xie >> --- >> v3: >> - pci_remap_iospace() sanitize its arguments instead - per Rafael >> >> v2: >> - Let the caller of ioremap_page_range() align the request by PAGE_SIZE - per Toshi >> >> drivers/pci/pci.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c >> index dbfe7c4..0eb0381 100644 >> --- a/drivers/pci/pci.c >> +++ b/drivers/pci/pci.c >> @@ -3544,6 +3544,9 @@ int pci_remap_iospace(const struct resource *res, phys_addr_t phys_addr) >> if (res->end > IO_SPACE_LIMIT) >> return -EINVAL; >> >> + if (!PAGE_ALIGNED(vaddr) || !PAGE_ALIGNED(resource_size(res))) >> + return -EINVAL; > > Most other callers of ioremap_page_range() are in the ioremap() path, > and they align phys_addr themselves. In some cases that results in a > mapping that covers more than necessary. For instance, see the > function comment at the x86 version of __ioremap_caller(). > > Is there any reason we couldn't similarly align vaddr and phys_addr > here? > > The acpi_pci_probe_root_resources() path you mention above basically > ignores the errors you're returning. Your patches will avoid the > panic, which is an improvement, but I/O port space will not work, and > I don't see anything that gives the user a hint about why not. > > If we could align vaddr and phys_addr (and possibly map more than > necessary), I/O port space would still work. Right, I will send another version, soon. Thanks Yisheng > >> return ioremap_page_range(vaddr, vaddr + resource_size(res), phys_addr, >> pgprot_device(PAGE_KERNEL)); >> #else >> -- >> 1.7.12.4 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > . >