From patchwork Tue Jun 19 06:44:21 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 10473351 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 61C5F60230 for ; Tue, 19 Jun 2018 06:45:19 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 54CF12882F for ; Tue, 19 Jun 2018 06:45:19 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 44EE728930; Tue, 19 Jun 2018 06: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=-2.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI autolearn=ham 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 B99712882F for ; Tue, 19 Jun 2018 06:45:18 +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:MIME-Version:Cc:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: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=Ym4X8pIW1lQ/KRMZT/UYnaczp97lwD1zFbX2k/5+d2o=; b=M7X8A9PxtgrKK8HDqHt/QLcZAC c2UZVqn9qg3FBwixmJus3uN2j6fjURJ4FdTgSevZje5WL0h2dTYRPsIuIP/AnWTG3uQpXDavERbzv JpwR70DYudks6xBV+wl6VRZ0pW5vjkWnk75wWnIMCcHbU6Dn1wNsg34wcYfCtq+xYFW27XUIarTqB oNbWwZWLp8LpdjFqlVhN4MUljlVW4K9vvH/T4+kE5QEPKtSCEY33HSYnQXajb9MsDwEP+jD0zot0Y lzAz8AM9y5mFL2iSF+kyzH+/0HS+BtNUx+mrbgLlzN54YHxUlTf5hi3xS5TXf2Y+HaggJ0ZXdwzas jk2Qy1Mw==; 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 1fVAO5-0004kk-3t; Tue, 19 Jun 2018 06:45:09 +0000 Received: from mail-pl0-x242.google.com ([2607:f8b0:400e:c01::242]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fVANF-0004Ci-PF for linux-arm-kernel@lists.infradead.org; Tue, 19 Jun 2018 06:44:28 +0000 Received: by mail-pl0-x242.google.com with SMTP id k1-v6so10419609plt.2 for ; Mon, 18 Jun 2018 23:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=Pz/8CC8YBSFoejKCIh8QPg8R9nqbiIkn1Y//vL6VGqY=; b=XmDJlI5cpt8Jvehh2vBfePFAiOA2rGtp7BY6xp3/cmIcbjfogDbdmJvQ2favs88yeC RG+/WubooC+BoY0l966+1IOBdZryN8GKoW5a9OHStmsivB/EFiCRz9kdTzFGxvgwvta8 tC3V5Xp4QMGNWNYPLsJdnsCvTwQIcYgDpF+1M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=Pz/8CC8YBSFoejKCIh8QPg8R9nqbiIkn1Y//vL6VGqY=; b=IlgUuCKP2sLcTNQb3SEwbAzSVFxiOCBubFhDQwxhUciIcd9e94uQ5xUC7glj+C8H3c UcJxU5JyanXQe87ibJtfAp3f5J1k5PlHW4C5YYZNg2tqL814NoJXDg1IQV7p4R03pLG3 +NLVEhd4EAjtMqg+ZnnVQl5TIW1K3fw5wt1K1XPuev2B07xQQEM6gpqsYu8l5Ul54CN1 rQB1qBq5WUNwP3TNNQRObk1v8Gf/GST+8vjBjYr9CdzIp5VsTimifzV+bC/NsbMXj6cl bjrIE0jZQjl110jd77evr2iE2jiBrtIUgNheciMsJLGJXdpRMqVpifkRa4USsBC79ulO yVpw== X-Gm-Message-State: APt69E0yVk77UPeoPR9UGG+bKu/AG/YSxYAGgstCOT9+bzrTqZ7z2UNC dwY7W837K9ReVeQT2SkccErE1A== X-Google-Smtp-Source: ADUXVKL8m21FzarNC2QeNDz6f4i3C1E8rKFjb0i2s/8k8M1nMv3mNqHBcvnyIjfifymyLzoZ/n9EzA== X-Received: by 2002:a17:902:bb81:: with SMTP id m1-v6mr17437964pls.117.1529390647314; Mon, 18 Jun 2018 23:44:07 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id 10-v6sm38423943pfs.111.2018.06.18.23.44.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jun 2018 23:44:06 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, akpm@linux-foundation.org, ard.biesheuvel@linaro.org Subject: [PATCH v2 1/4] arm64: export memblock_reserve()d regions via /proc/iomem Date: Tue, 19 Jun 2018 15:44:21 +0900 Message-Id: <20180619064424.6642-2-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180619064424.6642-1-takahiro.akashi@linaro.org> References: <20180619064424.6642-1-takahiro.akashi@linaro.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180618_234417_896842_58177AED X-CRM114-Status: GOOD ( 16.03 ) 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: mark.rutland@arm.com, lorenzo.pieralisi@arm.com, graeme.gregory@linaro.org, al.stone@linaro.org, bhsharma@redhat.com, tbaicar@codeaurora.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, james.morse@arm.com, hanjun.guo@linaro.org, sudeep.holla@arm.com, dyoung@redhat.com, linux-arm-kernel@lists.infradead.org MIME-Version: 1.0 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 From: James Morse There has been some confusion around what is necessary to prevent kexec overwriting important memory regions. memblock: reserve, or nomap? Only memblock nomap regions are reported via /proc/iomem, kexec's user-space doesn't know about memblock_reserve()d regions. Until commit f56ab9a5b73ca ("efi/arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP") the ACPI tables were nomap, now they are reserved and thus possible for kexec to overwrite with the new kernel or initrd. But this was always broken, as the UEFI memory map is also reserved and not marked as nomap. Exporting both nomap and reserved memblock types is a nuisance as they live in different memblock structures which we can't walk at the same time. Take a second walk over memblock.reserved and add new 'reserved' subnodes for the memblock_reserved() regions that aren't already described by the existing code. (e.g. Kernel Code) We use reserve_region_with_split() to find the gaps in existing named regions. This handles the gap between 'kernel code' and 'kernel data' which is memblock_reserve()d, but already partially described by request_standard_resources(). e.g.: | 80000000-dfffffff : System RAM | 80080000-80ffffff : Kernel code | 81000000-8158ffff : reserved | 81590000-8237efff : Kernel data | a0000000-dfffffff : Crash kernel | e00f0000-f949ffff : System RAM reserve_region_with_split needs kzalloc() which isn't available when request_standard_resources() is called, use an initcall. Reported-by: Bhupesh Sharma Reported-by: Tyler Baicar Suggested-by: Akashi Takahiro Signed-off-by: James Morse Fixes: d28f6df1305a ("arm64/kexec: Add core kexec support") CC: Ard Biesheuvel CC: Mark Rutland Reviewed-by: Ard Biesheuvel --- arch/arm64/kernel/setup.c | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c index 30ad2f085d1f..5b4fac434c84 100644 --- a/arch/arm64/kernel/setup.c +++ b/arch/arm64/kernel/setup.c @@ -241,6 +241,44 @@ static void __init request_standard_resources(void) } } +static int __init reserve_memblock_reserved_regions(void) +{ + phys_addr_t start, end, roundup_end = 0; + struct resource *mem, *res; + u64 i; + + for_each_reserved_mem_region(i, &start, &end) { + if (end <= roundup_end) + continue; /* done already */ + + start = __pfn_to_phys(PFN_DOWN(start)); + end = __pfn_to_phys(PFN_UP(end)) - 1; + roundup_end = end; + + res = kzalloc(sizeof(*res), GFP_ATOMIC); + if (WARN_ON(!res)) + return -ENOMEM; + res->start = start; + res->end = end; + res->name = "reserved"; + res->flags = IORESOURCE_MEM; + + mem = request_resource_conflict(&iomem_resource, res); + /* + * We expected memblock_reserve() regions to conflict with + * memory created by request_standard_resources(). + */ + if (WARN_ON_ONCE(!mem)) + continue; + kfree(res); + + reserve_region_with_split(mem, start, end, "reserved"); + } + + return 0; +} +arch_initcall(reserve_memblock_reserved_regions); + u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID }; void __init setup_arch(char **cmdline_p)