From patchwork Mon Jul 9 00:07:48 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 10513407 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 7F75A6032C for ; Mon, 9 Jul 2018 00:07:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6D998289E5 for ; Mon, 9 Jul 2018 00:07:48 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 61A31289F2; Mon, 9 Jul 2018 00:07:48 +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=unavailable 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 0B820289E5 for ; Mon, 9 Jul 2018 00:07:47 +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=AM3R6coMgRvHKA/DohgngUklxQuQwrq6p2EmLEwVTJw=; b=KulNmswcxtcxh5WXjrgJKoAmDN 37L6wAtAK2b63wqqMUrpPUNOTkpUxRRYsPCyINA0EcVUAsyclRRGODx7NFHDPkBpQ8fmKuM1ImfN3 XrCAAARavSOQN8WntpcX0LDeIFM0kivQYkAu8GqUjsCxaLExo2381F3oPZS+fpEYmPMa0c+3QpER1 BtGC/tXtZWXX2aILzfwFRgiTNhgv/TMofb8SYqNvgRuNWxAMLgU61Dr0DC0leug1wdSRgW0+PysJv JQVHl0IOR4kgS5hEWpZK6mgzDGKKoOtmT5h7+w2i6+sbp/mG2hBaI1fc7hhZ0po8b3cBoNDHiOFVv PqLtMT7Q==; 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 1fcJiQ-0000Uu-Dv; Mon, 09 Jul 2018 00:07:42 +0000 Received: from mail-pf0-x241.google.com ([2607:f8b0:400e:c00::241]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1fcJi8-0000Ef-4v for linux-arm-kernel@lists.infradead.org; Mon, 09 Jul 2018 00:07:27 +0000 Received: by mail-pf0-x241.google.com with SMTP id l9-v6so685093pff.9 for ; Sun, 08 Jul 2018 17:07:14 -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=F9qL97WIJTDKar0RATFRGa32DomSlp6yFEb0hpSLUU4=; b=kd2ptLTQ8wg2U2tCQ4/hsptK683fIZEYs8VbdMmThKMJGU/7s2YCOjFId5Ewr0cgFG na5HyqSagqJ14Nb8X02wK9JwQGxkD5nCDp6rwhp9dN8V9QP4Br3yDCbEyUJ0/RcDsGm7 gBTe/UI6U84Ig8xNsh/WW1TGjLKQaNxovn0xw= 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=F9qL97WIJTDKar0RATFRGa32DomSlp6yFEb0hpSLUU4=; b=uXnUMv3QEcz5MIMiNIkC/YI/VNa8GM0po04V42qDPjKnj6iKT4H+aVMSNsxj5JQKH/ GurrFS6UaEEhizfUEFOzLTjGbLPd5vACxiM3xYRlydcJMeGpnt87H7ZXIZxCTypCObu2 uzwiPDYaUo/Fr+cYRhOx1RF9F3wjkDJ9UYX4o7jkYDednLeb9j6RYQvvqK499aIwnoKM mYaaJncBToDFhe2bg9jN9seivMTBUFAbVozqVcirQxtJE/mDpnGEzmwWrLa48NBGVcXO IlZSO6VGWVuT2y9zNN9wTX7rZP5kXkBtKuiyjBrrnqATgtHtb2wXKeFhpwbGac9oJ/N2 4F2A== X-Gm-Message-State: APt69E3cWcPtAmx1Zx0xw38jgprZwYn/9mB7gFXsH3zHRpTo/Q3vlysz JdUb20uO4+QorKIPMOILztlcYQ== X-Google-Smtp-Source: AAOMgpcrG1irlTbZFj0LnRjTzNYrHGLfMuPQXENZyPCdi+zpXzl4C6uTe8hsZO+M7pJ+87jyG1v1sg== X-Received: by 2002:a62:5486:: with SMTP id i128-v6mr18832326pfb.166.1531094833749; Sun, 08 Jul 2018 17:07:13 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id f69-v6sm17703443pfc.23.2018.07.08.17.07.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jul 2018 17:07:13 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, ard.biesheuvel@linaro.org Subject: [PATCH v3 1/3] arm64: export memblock_reserve()d regions via /proc/iomem Date: Mon, 9 Jul 2018 09:07:48 +0900 Message-Id: <20180709000750.22172-2-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.17.0 In-Reply-To: <20180709000750.22172-1-takahiro.akashi@linaro.org> References: <20180709000750.22172-1-takahiro.akashi@linaro.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20180708_170724_196346_B75CBBF8 X-CRM114-Status: GOOD ( 15.38 ) 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") Reviewed-by: Ard Biesheuvel CC: Mark Rutland --- 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)