Received: by 10.192.165.148 with SMTP id m20csp5042394imm; Tue, 8 May 2018 20:49:01 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqEWUOKUxnmE3cqnGKItq+PnDGx1VH+X5AyrI/yPkR7T2k6CtVKZKqbnCj34Kowo5cmK2O3 X-Received: by 2002:a63:7a07:: with SMTP id v7-v6mr34572731pgc.343.1525837741005; Tue, 08 May 2018 20:49:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525837740; cv=none; d=google.com; s=arc-20160816; b=XlFit4+NmoCWOj5U8VCxSkFHvRZs/01OgAjYfES+S1EoHaJpv37+dM7uh8Fq+1zuU0 aR8fWKL3lwZhhC6qED15LJxosLRYB6GLtflTdmX5BxSc8MPU8iQDuf1ZQuuQxYuqzjq3 Mre/1ynKIVukwJezuob9Dbuje46pPK3zXP7gETVc/aTArhXnXQthZLBUYBEelLrGm3uI MuksWG592LgIisCgvD6CJuhSJERYTiaAC/k/3IWeaan85beLO3O9wqonlGujOg3njxBm v6DJOP3aE1gRE+dwbQP46H6Ynyih2voWRsEyQymw4M1m51bgGxwRkuZj9rzMdzoMOoQ0 4mKg== 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=aQBaiAEgy27ia7Bu5JGjrLkqRhco2r/AIEtY/elebFg=; b=VU2TkPEcxF4qgKlW3jHaUsnZnlLw3x9Am2xC+DV1T5hXREZBrZdQSTpFwl812WczC+ uqUEqLbPQgmmmOhY6eGbE4Ow5lk5ZX3D2Lgl9IEOA88L/Kfojiuzj9xH5ECLQLvG6/7/ PUWbhI9h/QioME+/5ikmUajJFRi4mXVSL0hEY6MazmBMKqgbA5288s3ImlYSTfiTUUBR RbcAYarUxZgFq84fNoO7hQtK+pCb2+jwQ87YdzNcAvMmwWHTnwlzpsLsSEzRNmBmOQU9 9Uwuu1ak6J9A/RmtnYsrKO0fonoIy43W5YPxxDf7KV5BYG7AQKPk6c/VaWfPR3skV0fl AfzQ== 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 c18-v6si24127161plo.185.2018.05.08.20.48.46; Tue, 08 May 2018 20:49:00 -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 S933717AbeEIDr1 (ORCPT + 99 others); Tue, 8 May 2018 23:47:27 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:7244 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933614AbeEIDrZ (ORCPT ); Tue, 8 May 2018 23:47:25 -0400 Received: from DGGEMS413-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 160CBCA1E6667; Wed, 9 May 2018 11:47:11 +0800 (CST) Received: from [127.0.0.1] (10.177.29.40) by DGGEMS413-HUB.china.huawei.com (10.3.19.213) with Microsoft SMTP Server id 14.3.361.1; Wed, 9 May 2018 11:47:05 +0800 Subject: Re: [PATCH v2 1/2] PCI ACPI: Avoid panic when PCI IO resource's size is not page aligned To: "Rafael J. Wysocki" References: <1522480343-37669-1-git-send-email-xieyisheng1@huawei.com> <3699960.UXjPS91TgB@aspire.rjw.lan> CC: "Rafael J. Wysocki" , Bjorn Helgaas , Len Brown , Linux PCI , ACPI Devel Maling List , Linux Kernel Mailing List , Hanjun Guo , "Jon Masters" , Toshi Kani , , Zhou Wang , "Lorenzo Pieralisi" , Sudeep Holla , Hanjun Guo From: Yisheng Xie Message-ID: <31dd8592-635c-ec88-2734-2fa9d4ce373e@huawei.com> Date: Wed, 9 May 2018 11:46:50 +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: Content-Type: text/plain; charset="utf-8" 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 Rafael, On 2018/5/9 5:20, Rafael J. Wysocki wrote: > On Mon, May 7, 2018 at 10:06 AM, Yisheng Xie wrote: >> >> >> On 2018/5/1 17:28, Rafael J. Wysocki wrote: >>>> drivers/acpi/pci_root.c | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c >>>>> index 6fc204a..b758ca3 100644 >>>>> --- a/drivers/acpi/pci_root.c >>>>> +++ b/drivers/acpi/pci_root.c >>>>> @@ -746,7 +746,7 @@ static void acpi_pci_root_remap_iospace(struct resource_entry *entry) >>>>> goto err; >>>>> >>>>> res->start = port; >>>>> - res->end = port + length - 1; >>>>> + res->end = PAGE_ALIGN(port + length) - 1; >>> Shouldn't pci_remap_iospace() sanitize its arguments instead? >> >> Yeah, I thought that pci_remap_iospace() will be called at many place, and presently I >> had not seen any problem at other place except acpi_pci_root_remap_iospace(). Anyway, >> sanitize arguments in pci_remap_iospace() can resolve the problem more thoroughly, but >> should more common, right? >> >> Therefore, is the follow change ok from your point of view? >> >> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c >> index e597655..8607298 100644 >> --- a/drivers/pci/pci.c >> +++ b/drivers/pci/pci.c >> @@ -3527,6 +3527,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; >> + >> return ioremap_page_range(vaddr, vaddr + resource_size(res), phys_addr, >> pgprot_device(PAGE_KERNEL)); >> #else > > I'd rather apply PAGE_ALIGN() to the arguments of ioremap_page_range() > and call it anyway. It will fail if the mapping cannot be created. > Hmm, here is a corner case which take 64k page size as an example: step 1. someone call pci_remap_iospace() with res: res->start 0x1000, resource_size(res) 0x1000 after PAGE_ALIGN(), the arguments of ioremap_page_range() will be addr: (PCI_IOBASE + PAGE_SIZE), end: (PCI_IOBASE + 2*PAGE_SIZE) and ioremap_page_range will be ok. step 2. another one call pci_remap_iospace() with res: res->start 0x2000, resource_size(res) 0x1000 after PAGE_ALIGN(), the arguments of ioremap_page_range() also will be: addr: (PCI_IOBASE + PAGE_SIZE), end: (PCI_IOBASE + 2*PAGE_SIZE) then ioremap_page_range() will also trigger BUG_ON(!pte_none(*pte)); for the pte is not none after step 1, right? ps, if let addr = vaddr && PAGE_MASK, above case seems also will trigger BUG_ON. Actually, I am not sure whether the above case is exist in real system. Thanks Yisheng > . >