From patchwork Wed Sep 27 09:41:25 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhenzhong Duan X-Patchwork-Id: 9973633 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 3F57960375 for ; Wed, 27 Sep 2017 09:45:19 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 20C4028CC0 for ; Wed, 27 Sep 2017 09:45:19 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1584E29126; Wed, 27 Sep 2017 09:45:19 +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=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 9EC3528CC0 for ; Wed, 27 Sep 2017 09:45:18 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dx8qb-0003ow-BT; Wed, 27 Sep 2017 09:41:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dx8qa-0003oq-Bo for xen-devel@lists.xenproject.org; Wed, 27 Sep 2017 09:41:40 +0000 Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id 10/CE-02046-3527BC95; Wed, 27 Sep 2017 09:41:39 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGIsWRWlGSWpSXmKPExsUyZ7p8oG5w0el IgzfHWCy+b5nM5MDocfjDFZYAxijWzLyk/IoE1oyNRxewF+xRqOi9FdzAeFimi5GLQ0hgMpPE 07N7mCCcv4wSJxa8ZYdwNjBK3DrUwNLFyMnBKyAocXLmEyjbSqJ3/3Qwm0VAW+L25MdsIDabg IHEmunfwGwRgXKJ83vvgA1iFpjJKLH6zFNGkISwQKhE99TbrCC2hICSxL+t3UCDOICK1CXWzx MCCTMDzVy28DUzRFhaYvk/DohqY4n2txfZJjDyz0Jy0SyE5llImmchNC9gZFnFqFGcWlSWWqR raKyXVJSZnlGSm5iZo2toYKyXm1pcnJiempOYVKyXnJ+7iREYmgxAsINx23bPQ4ySHExKoryP Mk5HCvEl5adUZiQWZ8QXleakFh9ilOHgUJLgdSsEygkWpaanVqRl5gCjBCYtwcGjJML7vQAoz VtckJhbnJkOkTrFaMxxbNPlP0wcHTfv/mESYsnLz0uVEuc1BJkkAFKaUZoHNwgWvZcYZaWEeR mBThPiKUgtys0sQZV/xSjOwagkzOsHMoUnM68Ebt8roFOYgE7pnXoC5JSSRISUVANj9+Z8ZSv BlK2TBVYJHLEokdumtU6d6dLsuRHLlZ8d3S+g+0/5g3H1FoniRD6DoN7fxhNWzP9m9m1F1MaO WSZGNzfUMhQFPH//xif53e4NyQ7rDR1fxba/Cg1ZsdmktN4g+1IMY0PbnOkWdxZ9i1kicFr9I mdjykZPOwb+CpmKiiPbjaZHCHIqsRRnJBpqMRcVJwIAyoh8NtkCAAA= X-Env-Sender: zhenzhong.duan@oracle.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1506505297!58653733!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: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 57647 invoked from network); 27 Sep 2017 09:41:38 -0000 Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by server-4.tower-31.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 27 Sep 2017 09:41:38 -0000 Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v8R9fR65008009 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Sep 2017 09:41:27 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v8R9fQ4h017647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Sep 2017 09:41:27 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v8R9fQsb020584; Wed, 27 Sep 2017 09:41:26 GMT MIME-Version: 1.0 Message-ID: <85bd42d5-b0d2-40f5-81a9-14cb51ec4503@default> Date: Wed, 27 Sep 2017 02:41:25 -0700 (PDT) From: Zhenzhong Duan To: , , , , X-Mailer: Zimbra on Oracle Beehive Content-Disposition: inline X-Source-IP: aserv0022.oracle.com [141.146.126.234] Cc: xen-devel@lists.xenproject.org, x86@kernel.org, joe.jin@oracle.com, linux-kernel@vger.kernel.org, srinivas.eeda@oracle.com Subject: [Xen-devel] [PATCH v2] Call xen_cleanhighmap() with 4MB aligned for page tables mapping X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP When bootup a PVM guest with large memory(Ex.240GB), XEN provided initial mapping overlaps with kernel module virtual space. When mapping in this space is cleared by xen_cleanhighmap(), in certain case there could be an 2MB mapping left. This is due to XEN initialize 4MB aligned mapping but xen_cleanhighmap() finish at 2MB boundary. When module loading is just on top of the 2MB space, got below warning: WARNING: at mm/vmalloc.c:106 vmap_pte_range+0x14e/0x190() Call Trace: [] warn_alloc_failed+0xf3/0x160 [] __vmalloc_area_node+0x182/0x1c0 [] ? module_alloc_update_bounds+0x1e/0x80 [] __vmalloc_node_range+0xa7/0x110 [] ? module_alloc_update_bounds+0x1e/0x80 [] module_alloc+0x64/0x70 [] ? module_alloc_update_bounds+0x1e/0x80 [] module_alloc_update_bounds+0x1e/0x80 [] move_module+0x27/0x150 [] layout_and_allocate+0x120/0x1b0 [] load_module+0x78/0x640 [] ? security_file_permission+0x8b/0x90 [] sys_init_module+0x62/0x1e0 [] system_call_fastpath+0x16/0x1b Then the mapping of 2MB is cleared, finally oops when the page in that space is accessed. BUG: unable to handle kernel paging request at ffff880022600000 IP: [] clear_page_c_e+0x7/0x10 PGD 1788067 PUD 178c067 PMD 22434067 PTE 0 Oops: 0002 [#1] SMP Call Trace: [] ? prep_new_page+0x127/0x1c0 [] get_page_from_freelist+0x1e2/0x550 [] ? ii_iovec_copy_to_user+0x90/0x140 [] __alloc_pages_nodemask+0x12d/0x230 [] alloc_pages_vma+0xc6/0x1a0 [] ? pte_mfn_to_pfn+0x7d/0x100 [] do_anonymous_page+0x16b/0x350 [] handle_pte_fault+0x1e4/0x200 [] ? xen_pmd_val+0xe/0x10 [] ? __raw_callee_save_xen_pmd_val+0x11/0x1e [] handle_mm_fault+0x15b/0x270 [] do_page_fault+0x140/0x470 [] page_fault+0x25/0x30 Call xen_cleanhighmap() with 4MB aligned for page tables mapping to fix it. The unnecessory call of xen_cleanhighmap() in DEBUG mode is also removed. -v2: add comment about XEN alignment from Juergen. References: https://lists.xen.org/archives/html/xen-devel/2012-07/msg01562.html Signed-off-by: Zhenzhong Duan Reviewed-by: Juergen Gross --- arch/x86/xen/mmu_pv.c | 13 ++++--------- 1 files changed, 4 insertions(+), 9 deletions(-) diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c index 7330cb3..aa0f7e2 100644 --- a/arch/x86/xen/mmu_pv.c +++ b/arch/x86/xen/mmu_pv.c @@ -1238,21 +1238,16 @@ static void __init xen_pagetable_cleanhighmap(void) * from _brk_limit way up to the max_pfn_mapped (which is the end of * the ramdisk). We continue on, erasing PMD entries that point to page * tables - do note that they are accessible at this stage via __va. - * For good measure we also round up to the PMD - which means that if + * As Xen is aligning the memory end to a 4MB boundary, for good + * measure we also round up to PMD_SIZE * 2 - which means that if * anybody is using __ka address to the initial boot-stack - and try * to use it - they are going to crash. The xen_start_info has been * taken care of already in xen_setup_kernel_pagetable. */ addr = xen_start_info->pt_base; - size = roundup(xen_start_info->nr_pt_frames * PAGE_SIZE, PMD_SIZE); + size = xen_start_info->nr_pt_frames * PAGE_SIZE; - xen_cleanhighmap(addr, addr + size); + xen_cleanhighmap(addr, roundup(addr + size, PMD_SIZE * 2)); xen_start_info->pt_base = (unsigned long)__va(__pa(xen_start_info->pt_base)); -#ifdef DEBUG - /* This is superfluous and is not necessary, but you know what - * lets do it. The MODULES_VADDR -> MODULES_END should be clear of - * anything at this stage. */ - xen_cleanhighmap(MODULES_VADDR, roundup(MODULES_VADDR, PUD_SIZE) - 1); -#endif } #endif