From patchwork Thu Apr 4 15:59:59 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: John Garry X-Patchwork-Id: 10885871 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id BFF4917EE for ; Thu, 4 Apr 2019 16:00:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A271928AD0 for ; Thu, 4 Apr 2019 16:00:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A047628B45; Thu, 4 Apr 2019 16:00:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 016AB28B5C for ; Thu, 4 Apr 2019 16:00:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Date:Subject:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=VvYbYj1BRNdIQh69y36C5JTL7nPBtKNYfUuR1OY4S9k=; b=jzRV7y+aDsiySZ 0nI/D6YGw0Ho6QrUEHwVcPdIl4tNhTGM9yDo3ACh4OLLFUEbtiAb9DNY71EPQyHrrHh95m+1llRLe IA9r6pUMV2e8nuEF+P1Q8+xZ8sb/4UhnghAZyiq6mOH6T3qp0aXv9qnuc5Q3kaNkuBU85OFbLUnty oVmD+qQcUl9H7vTj1cxjZcG2NFhBXgS8gvNRBL9/YoVEMzApeROWvr4AHPciqDffYgvmVQRi/BxDW ZQZrB3d7rGjM8XtmX7xjvGFCRfmjQCGxeDM0WPUcQQrVE9DYOnC07ThfS5Ixy454Za4XF0QJ0mPHu TYqdLDERk2RA8V4lmIsQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hC4n9-0003gd-A3; Thu, 04 Apr 2019 16:00:39 +0000 Received: from szxga06-in.huawei.com ([45.249.212.32] helo=huawei.com) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hC4mz-0003We-Up for linux-arm-kernel@lists.infradead.org; Thu, 04 Apr 2019 16:00:31 +0000 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id CB6438943CF24F2DBB85; Fri, 5 Apr 2019 00:00:23 +0800 (CST) Received: from localhost.localdomain (10.67.212.75) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.408.0; Fri, 5 Apr 2019 00:00:17 +0800 From: John Garry To: , , , Subject: [RFC PATCH v3 1/4] resource: Request IO port regions from children of ioport_resource Date: Thu, 4 Apr 2019 23:59:59 +0800 Message-ID: <1554393602-152448-2-git-send-email-john.garry@huawei.com> X-Mailer: git-send-email 2.8.1 In-Reply-To: <1554393602-152448-1-git-send-email-john.garry@huawei.com> References: <1554393602-152448-1-git-send-email-john.garry@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.67.212.75] X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190404_090030_165777_D2835573 X-CRM114-Status: GOOD ( 14.82 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: wangkefeng.wang@huawei.com, linux-pci@vger.kernel.org, John Garry , will.deacon@arm.com, linux-kernel@vger.kernel.org, linuxarm@huawei.com, andy.shevchenko@gmail.com, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, bp@suse.de, linux@roeck-us.net Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Virus-Scanned: ClamAV using ClamSMTP Currently request_region() requests an IO port region directly from the top resource, ioport_resource. There is an issue here, in that drivers may successfully request an IO port region even if the IO port region has not even been mapped in (in pci_remap_iospace()). This may lead to crashes when the system has no PCI host, or, has a host but it has failed enumeration, while drivers still attempt to access PCI IO ports, as below: root@(none)$root@(none)$ insmod f71882fg.ko Unable to handle kernel paging request at virtual address ffff7dfffee0002e Mem abort info: ESR = 0x96000046 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000046 CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp = (____ptrval____) [ffff7dfffee0002e] pgd=000000000141c003, pud=000000000141d003, pmd=0000000000000000 Internal error: Oops: 96000046 [#1] PREEMPT SMP Modules linked in: f71882fg(+) CPU: 8 PID: 2732 Comm: insmod Not tainted 5.1.0-rc1-00002-gab1a0e9200b8-dirty #102 Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018 pstate: 80000005 (Nzcv daif -PAN -UAO) pc : logic_outb+0x54/0xb8 lr : f71882fg_find+0x64/0x390 [f71882fg] sp : ffff000013393aa0 x29: ffff000013393aa0 x28: ffff000008b98b10 x27: ffff000013393df0 x26: 0000000000000100 x25: ffff801f8c872d30 x24: ffff000011420000 x23: ffff801fb49d2940 x22: ffff000011291000 x21: 000000000000002e x20: 0000000000000087 x19: ffff000013393b44 x18: ffffffffffffffff x17: 0000000000000000 x16: 0000000000000000 x15: ffff00001127d6c8 x14: ffff801f8cfd691c x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000003 x10: 0000801feace2000 x9 : 0000000000000000 x8 : ffff841fa654f280 x7 : 0000000000000000 x6 : 0000000000ffc0e3 x5 : ffff000011291360 x4 : ffff801fb4949f00 x3 : 0000000000ffbffe x2 : 76e767a63713d500 x1 : ffff7dfffee0002e x0 : ffff7dfffee00000 Process insmod (pid: 2732, stack limit = 0x(____ptrval____)) Call trace: logic_outb+0x54/0xb8 f71882fg_find+0x64/0x390 [f71882fg] f71882fg_init+0x38/0xc70 [f71882fg] do_one_initcall+0x5c/0x198 do_init_module+0x54/0x1b0 load_module+0x1dc4/0x2158 __se_sys_init_module+0x14c/0x1e8 __arm64_sys_init_module+0x18/0x20 el0_svc_common+0x5c/0x100 el0_svc_handler+0x2c/0x80 el0_svc+0x8/0xc Code: d2bfdc00 f2cfbfe0 f2ffffe0 8b000021 (39000034) ---[ end trace fd4f35b610829a48 ]--- Segmentation fault root@(none)$ Note that the f71882fg driver correctly calls request_muxed_region(). This issue was originally reported in [1]. This patch changes the functionality of request{muxed_}_region() to request a region from a direct child descendent of the top ioport_resource. In this, if the IO port region has not been mapped for a particular IO region, the PCI IO resource would also not have been inserted, and so a suitable child region will not exist. As such, request_{muxed_}region() calls will fail. A side note: there are many drivers in the kernel which fail to even call request_{muxed_}region() prior to IO port accesses, and they also need to be fixed (to call request_{muxed_}region(), as appropriate) separately. [1] https://lore.kernel.org/linux-pci/56F209A9.4040304@huawei.com Signed-off-by: John Garry --- include/linux/ioport.h | 11 ++++++++--- kernel/resource.c | 28 ++++++++++++++++++++++++++++ 2 files changed, 36 insertions(+), 3 deletions(-) diff --git a/include/linux/ioport.h b/include/linux/ioport.h index da0ebaec25f0..76288b8783ff 100644 --- a/include/linux/ioport.h +++ b/include/linux/ioport.h @@ -217,15 +217,20 @@ static inline bool resource_contains(struct resource *r1, struct resource *r2) /* Convenience shorthand with allocation */ -#define request_region(start,n,name) __request_region(&ioport_resource, (start), (n), (name), 0) -#define request_muxed_region(start,n,name) __request_region(&ioport_resource, (start), (n), (name), IORESOURCE_MUXED) +#define request_region(start, n, name) __request_region_from_children(&ioport_resource, (start), (n), (name), 0) +#define request_muxed_region(start, n, name) __request_region_from_children(&ioport_resource, (start), (n), (name), IORESOURCE_MUXED) #define __request_mem_region(start,n,name, excl) __request_region(&iomem_resource, (start), (n), (name), excl) #define request_mem_region(start,n,name) __request_region(&iomem_resource, (start), (n), (name), 0) #define request_mem_region_exclusive(start,n,name) \ __request_region(&iomem_resource, (start), (n), (name), IORESOURCE_EXCLUSIVE) #define rename_region(region, newname) do { (region)->name = (newname); } while (0) -extern struct resource * __request_region(struct resource *, +extern struct resource *__request_region(struct resource *, + resource_size_t start, + resource_size_t n, + const char *name, int flags); + +extern struct resource *__request_region_from_children(struct resource *, resource_size_t start, resource_size_t n, const char *name, int flags); diff --git a/kernel/resource.c b/kernel/resource.c index 92190f62ebc5..87ed200eda8b 100644 --- a/kernel/resource.c +++ b/kernel/resource.c @@ -1097,6 +1097,34 @@ resource_size_t resource_alignment(struct resource *res) static DECLARE_WAIT_QUEUE_HEAD(muxed_resource_wait); +/** + * __request_region_from_children - create a new busy region from a child + * @parent: parent resource descriptor + * @start: resource start address + * @n: resource region size + * @name: reserving caller's ID string + * @flags: IO resource flags + */ +struct resource *__request_region_from_children(struct resource *parent, + resource_size_t start, + resource_size_t n, + const char *name, int flags) +{ + struct resource *res = __request_region(parent, start, n, name, flags); + + if (res && res->parent == parent) { + /* + * This is a direct descendent of the parent, which is + * what we didn't want. + */ + __release_region(parent, start, n); + res = NULL; + } + + return res; +} +EXPORT_SYMBOL(__request_region_from_children); + /** * __request_region - create a new busy resource region * @parent: parent resource descriptor