From nobody Wed Apr 24 09:14:04 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org ARC-Seal: i=1; a=rsa-sha256; t=1565352953; cv=none; d=zoho.com; s=zohoarc; b=WgoOpvz6uQz084rsZHftm6nzcHRNok2XQgYnmewZJPgMOcPO3xnbz+dybPGu7LwAMnDyfnNVs7xRwyOcg/yYhha+YJdN/LKWcrIv2J5A1xIMXHQtEZxxuwnrIDD5P0d8fhe9GKeUO9J19Gw+E4AOBMp53kvraHTu3zLwvq3Nb3k= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1565352953; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To:ARC-Authentication-Results; bh=wwEhmXQFK+pLKQNyoQaF9ajCYmExY1JUn6auXD67hjw=; b=C02qzAI9D7tIaAPX/jeGNB63QrcfZmPuisCyl4kAFShk6WjjjsHxszMP2eXqGO7YGK5fiMgEmSWNbxpMXC8AgAEENo4L5cEI+QuGK8HIDVxAkBHOA3Lf4XAMXIEqH8EYfm81JuoHwJ7c0yK9NMvP2PMBoimRUtFvjCOyh1jeFBE= ARC-Authentication-Results: i=1; mx.zoho.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1565352953893181.37829946626312; Fri, 9 Aug 2019 05:15:53 -0700 (PDT) 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 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) X-Inumbo-ID: 494a55cc-ba9f-11e9-ad35-7fd1043a7b75 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" 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 Acked-by: Stefano Stabellini Reviewed-by: Jan Beulich Tested-by: Stefano Stabellini 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 =3D false; =20 /* + * 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-- <=3D 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.). --=20 2.11.0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel