From patchwork Fri Aug 9 12:14:40 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julien Grall X-Patchwork-Id: 11086373 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 6C69A1399 for ; Fri, 9 Aug 2019 12:16:08 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4D27728A2E for ; Fri, 9 Aug 2019 12:16:08 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 410FB28AA1; Fri, 9 Aug 2019 12:16:08 +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,MAILING_LIST_MULTI, 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 AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id D70C728A2E for ; Fri, 9 Aug 2019 12:16:07 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hw3nK-0001iq-QM; Fri, 09 Aug 2019 12:14:54 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1hw3nJ-0001ii-Nt for xen-devel@lists.xenproject.org; Fri, 09 Aug 2019 12:14:53 +0000 X-Inumbo-ID: 494a55cc-ba9f-11e9-ad35-7fd1043a7b75 Received: from foss.arm.com (unknown [217.140.110.172]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 494a55cc-ba9f-11e9-ad35-7fd1043a7b75; Fri, 09 Aug 2019 12:14:50 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 006491596; Fri, 9 Aug 2019 05:14:50 -0700 (PDT) Received: from e108454-lin.cambridge.arm.com (e108454-lin.cambridge.arm.com [10.1.196.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4DA043F706; Fri, 9 Aug 2019 05:14:48 -0700 (PDT) From: Julien Grall To: xen-devel@lists.xenproject.org Date: Fri, 9 Aug 2019 13:14:40 +0100 Message-Id: <20190809121440.5668-1-julien.grall@arm.com> X-Mailer: git-send-email 2.11.0 Subject: [Xen-devel] [PATCH] xen/page_alloc: Keep away MFN 0 from the buddy allocator X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Ian Jackson , Jeff Kubascik , Tim Deegan , Julien Grall , Jan Beulich , Stewart.Hildebrand@dornerworks.com, Jarvis.Roach@dornerworks.com MIME-Version: 1.0 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP Combining of buddies happens only such that the resulting larger buddy is still order-aligned. To cross a zone boundary while merging, the implication is that both the buddy [0, 2^n-1] and the buddy [2^n, 2^(n+1)] are free. Ideally we want to fix the allocator, but for now we can just prevent adding the MFN 0 in the allocator. On x86, the MFN 0 is already kept away from the buddy allocator. So the bug can only happen on Arm platform where the first memory bank is starting at 0. As this is a specific to the allocator, the MFN 0 is removed in the common code to cater all the architectures (current and future). Reported-by: Jeff Kubascik Signed-off-by: Julien Grall Reviewed-by: Jan Beulich Acked-by: Stefano Stabellini Tested-by: Stefano Stabellini Signed-off-by: Jeff Kubascik Tested-by: Stewart Hildebrand --- Cc: Jarvis.Roach@dornerworks.com Cc: Stewart.Hildebrand@dornerworks.com I am not sure I fully understood the exact problem when MFN 0 is given to the allocator. Feel free to suggest a better explanation. Can anyone able to reproduce the bug test where the patch effectively solve the crash? --- xen/common/page_alloc.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/xen/common/page_alloc.c b/xen/common/page_alloc.c index 453b303b5b..42b8a8ce23 100644 --- a/xen/common/page_alloc.c +++ b/xen/common/page_alloc.c @@ -1759,6 +1759,18 @@ static void init_heap_pages( bool idle_scrub = false; /* + * Keep MFN 0 away from the buddy allocator to avoid crossing zone + * boundary when merging two buddies. + */ + if ( !mfn_x(page_to_mfn(pg)) ) + { + if ( nr_pages-- <= 1 ) + return; + pg++; + } + + + /* * Some pages may not go through the boot allocator (e.g reserved * memory at boot but released just after --- kernel, initramfs, * etc.).