From patchwork Wed Sep 27 03:03:45 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zhenzhong Duan X-Patchwork-Id: 9972997 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 091F460393 for ; Wed, 27 Sep 2017 03:07:59 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id EE86F28F04 for ; Wed, 27 Sep 2017 03:07:58 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E9E8828CEC; Wed, 27 Sep 2017 03:07:58 +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=-3.7 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RCVD_IN_SORBS_SPAM 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 2150128CEC for ; Wed, 27 Sep 2017 03:07:57 +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 1dx2do-0006xN-PX; Wed, 27 Sep 2017 03:04:04 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dx2dn-0006xH-Ak for xen-devel@lists.xenproject.org; Wed, 27 Sep 2017 03:04:03 +0000 Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id 9A/DA-18674-2251BC95; Wed, 27 Sep 2017 03:04:02 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRWlGSWpSXmKPExsXSO6nOVVdJ9HS kwfSdLBbft0xmcmD0OPzhCksAYxRrZl5SfkUCa8aSpnWsBcfkK87ufMzewPhMuouRi0NIYCKT xMeve9khnL+MEvdXTWOGcDYySvxbdoOti5GTg1dAUOLkzCcsELaVxOtnH8DiLALaErs/LGEFs dkEDCTWTP8GFhcRKJc4v/cO2FRmgYWMEo0LnjGCJIQFgiSmP5oGZksIKEn829oNNJQDqEhdYv 08IZAwM9DMZQtfM0OEpSWW/+OAqDaUOP1wG+MERv5ZSC6ahdA8C0nzLITmBYwsqxg1ilOLylK LdI2M9JKKMtMzSnITM3N0DQ1M9XJTi4sT01NzEpOK9ZLzczcxAoOznoGBcQfjnna/Q4ySHExK orw1/09FCvEl5adUZiQWZ8QXleakFh9ilOHgUJLgTRQ5HSkkWJSanlqRlpkDjBOYtAQHj5II7 2phoDRvcUFibnFmOkTqFKMxx7FNl/8wcXTcvPuHSYglLz8vVUqcNxdkkgBIaUZpHtwgWPxeYp SVEuZlZGBgEOIpSC3KzSxBlX/FKM7BqCTMWwoyhSczrwRu3yugU5iATumdegLklJJEhJRUA6N mQ1vgXlkmA8HAx3N0ufcLXoh7uWWZ2WPNACXVV+WdibnsG/P0SnOCPksFpJm1iFoy5m/c3fMn wG/JEclnZ2XmHBCMSsrzmTlx+5fguA+RL9Y7TTw861bx602xthxld79ZZuxbnHuS+86iaTbxL HGCVjcjghb8k402CY9Mcww2b36eIT5dVImlOCPRUIu5qDgRAGoQ0WTaAgAA X-Env-Sender: zhenzhong.duan@oracle.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1506481440!99385448!1 X-Originating-IP: [141.146.126.69] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTQxLjE0Ni4xMjYuNjkgPT4gMjc3MjE4\n X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31451 invoked from network); 27 Sep 2017 03:04:01 -0000 Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 27 Sep 2017 03:04:01 -0000 Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v8R33mPC028276 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Sep 2017 03:03:49 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v8R33l2a013157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Sep 2017 03:03:48 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v8R33jMj006487; Wed, 27 Sep 2017 03:03:45 GMT MIME-Version: 1.0 Message-ID: Date: Tue, 26 Sep 2017 20:03:45 -0700 (PDT) From: Zhenzhong Duan To: , , , , X-Mailer: Zimbra on Oracle Beehive Content-Disposition: inline X-Source-IP: userv0021.oracle.com [156.151.31.71] Cc: xen-devel@lists.xenproject.org, x86@kernel.org, Joe Jin , linux-kernel@vger.kernel.org, srinivas.eeda@oracle.com Subject: [Xen-devel] [PATCH] 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. References: https://lists.xen.org/archives/html/xen-devel/2012-07/msg01562.html Signed-off-by: Zhenzhong Duan --- arch/x86/xen/mmu_pv.c | 12 +++--------- 1 files changed, 3 insertions(+), 9 deletions(-) diff --git a/arch/x86/xen/mmu_pv.c b/arch/x86/xen/mmu_pv.c index 7330cb3..3628d97 100644 --- a/arch/x86/xen/mmu_pv.c +++ b/arch/x86/xen/mmu_pv.c @@ -1238,21 +1238,15 @@ 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 + * For good measure we also round up to the PMD*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