From patchwork Mon Jul 23 01:57:28 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 142526 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp5522470ljj; Sun, 22 Jul 2018 18:59:16 -0700 (PDT) X-Google-Smtp-Source: AAOMgpf9vuvAr71ZqiQ2uUy6PI0Qk3hIS4urGA3ZcYxwCppJj42qikUzPGViLtmF6C2blYvz9kb0 X-Received: by 2002:a17:902:7c89:: with SMTP id y9-v6mr10980485pll.187.1532311156119; Sun, 22 Jul 2018 18:59:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532311156; cv=none; d=google.com; s=arc-20160816; b=JtyU6N095APMBvzYjma8SteJLw2HbWtOafPpQImmW/3W5nZN3D8uHKqQx+orG8sytJ 2+sWtBC3kDNGkp3tTyJNIa/r6pSosfRPl/07m2X0Ibu/MrRmhndVkoj90pZim3uTGqrW YIXBhVNO1eqf9o/AJnd1AI25Pmgqskgm5smGxQ0SglrAWWYT7MpUpb4fAj7BBJYTI5Jr Ll1EOYGKMywmQ88wDjyES0z+OetsuuEB6Suwpm6W5bRDBmqBaNfbYh4b24UnyO4CFRBa WonoF6f2ajyvn3fcMEvCvRtiwLvm/Kmi9TPwxy2TLhQO6ZfjzrN6XF4v0aE4guRbpBYa mc8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=VxevqCZhbKQ45BiJjQYFdciJrVc/rEp2DL/VeorXBAY=; b=KZVHrwlXcJO55+kqvo8mAvjuRb48NffQ/+HkItsnwZmQKulRTiaCS9oArnYAdyOBc0 pv5EvI+e6UKzctJEXFNya+pkh/u/vI+SePr3TxTQo6zKguFOr0zJHOIfux8QKTwrwxbw Wbj81XBBD75EZPS5I/Zvqz2VP09q3b/+2hKTaestMlwS6EQZ5BDrPDZTZixNpZ7jO6XK O0BT0WkoKtG0OmAr0KW5wH6rmjbpwkCL5eyeRiUbOR6m7OG0DWyyXKMCGiN0UdUz97nj TCXZa4BaeU2lurMfHJ8x1nI+nlucnh/U1LJJ/MMALlgG+dkBQLjV54eRt2TNtTGNRbzA TcVw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=gnuUno+O; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x62-v6si7638176pfa.80.2018.07.22.18.59.15; Sun, 22 Jul 2018 18:59:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=gnuUno+O; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731287AbeGWC57 (ORCPT + 31 others); Sun, 22 Jul 2018 22:57:59 -0400 Received: from mail-pl0-f68.google.com ([209.85.160.68]:34512 "EHLO mail-pl0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731059AbeGWC57 (ORCPT ); Sun, 22 Jul 2018 22:57:59 -0400 Received: by mail-pl0-f68.google.com with SMTP id f6-v6so7543500plo.1 for ; Sun, 22 Jul 2018 18:59:12 -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=VxevqCZhbKQ45BiJjQYFdciJrVc/rEp2DL/VeorXBAY=; b=gnuUno+OgQw9cCj7YXXmKBGdCpWCmY1R3+e52F2/cMxWD/ODZpv21K+jL+KbwNYIJ2 9s1Y8HIOctFjO17sUm3QXi7ZPLl/P3LKxeZErMVV6PRZyKRVEiPwzCk1lPUz0WejJJEU EFbWwLLpoLysdhjMvkClHiWG7B/9WtNjk6YTU= 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=VxevqCZhbKQ45BiJjQYFdciJrVc/rEp2DL/VeorXBAY=; b=BP5nasXwCo8//ER3ELcDqCD6HQfwCExrQ4oV0M2s3rrgvFFPzQHEKwIiY6/hnTopUF EWvu0XEpNe7WFLciDIKyZ3prZTAHYLa7zQ9xG11gsgFw5nkclWEdrMRA3EZF1cGlkbrG 8OYsb4FchFIvOJUMKLhR807Ygdressg6mXmJbQzv/l8sf2yX1uUlwzVRBgaGAFV83Q4A OcJVuh3/BXhw7j6rGHxuXbJ6QAAg1UG9mwzPl34/mT5zOZef556DRWSZ8rOYHzZ7Vekj 63jndd7BO7LjfC9PVMQiqnIrVdp2zJ9EgjvA/90w/1IK+LAEQ2qn/Zbr7b7DuqGCScgK dgZA== X-Gm-Message-State: AOUpUlH+ahHFAh8hrk7RTXnqKwEZRv8ptl39nG1Gvwi0ERpJ689QBe6K vN+MYtY9etr10CEzPT+nAoHR7A== X-Received: by 2002:a17:902:8645:: with SMTP id y5-v6mr10978442plt.334.1532311152593; Sun, 22 Jul 2018 18:59:12 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id 85-v6sm20185621pgd.81.2018.07.22.18.59.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jul 2018 18:59:12 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, rjw@rjwysocki.net, lenb@kernel.org, ard.biesheuvel@linaro.org Cc: tbaicar@codeaurora.org, bhsharma@redhat.com, dyoung@redhat.com, james.morse@arm.com, mark.rutland@arm.com, al.stone@linaro.org, graeme.gregory@linaro.org, hanjun.guo@linaro.org, lorenzo.pieralisi@arm.com, sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org Subject: [PATCH v4 1/5] arm64: export memblock_reserve()d regions via /proc/iomem Date: Mon, 23 Jul 2018 10:57:28 +0900 Message-Id: <20180723015732.24252-2-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180723015732.24252-1-takahiro.akashi@linaro.org> References: <20180723015732.24252-1-takahiro.akashi@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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(+) -- 2.18.0 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) From patchwork Mon Jul 23 01:57:29 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 142527 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp5522532ljj; Sun, 22 Jul 2018 18:59:25 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdVjpUUDfG4NWKK+z52rYJWdlv8VIA39Rx133GLNVeOyAYboPHFVsPjFCPzqkNR47yiE7R2 X-Received: by 2002:a17:902:18a:: with SMTP id b10-v6mr11197225plb.62.1532311165531; Sun, 22 Jul 2018 18:59:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532311165; cv=none; d=google.com; s=arc-20160816; b=HUBUMGTHNf6vyMxMj3Tufyly+xsJ5yrEk0K8iLEFUGxMz51j1J93iSjpNun/3LPvn1 XAm5ftdi5E/BhAQzxFKMxGlfn8pnLSiUMpJJvrgS1nU/IfzpGLWuHiXyrxf7Hz5L0fBL 77wSV+VMLDhDYCw7RNgwjT/B25H7t6jBm4h4d9shWlLoxUsGjOsjb3byooJsGy7UhxU7 lL4Xo7E1/FZIFd0iqlHvKhcTP4krMRqUudRqw6/mlth4NO+IlLsQX1IdCMEeXn9dR6VX lRLE7BAfp7c0i2HGp5CAN22r9wAIqJH2bP7x5javIV1ATQYQL56bx/B2Ux3LxxxH2133 Bdzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=A1OqVoZAh5Xl0rWEI6oRjLgOW69kgPoUkzG/O/9JyGg=; b=1Ga9WE2M2OZYZ2inSY92AqFKb55SJJ8HpNVZL1+hloDv4YXcfl0ZZ1aDVsg7cgIp4m dLnkd5WyWgHmFYdP32GGVWgBnYC+gLXniUWGCHbJfx0I2jnwMlEYSOn0EtbHt9RbMHPT Ny9b5sS4GAPKG/TT6AN5H5f+eeYOTkWED/P1bj96uXt5+7hxdd+eQ122r1v3yISQ1RNW 0IkI5SoBzSDTcced7HxG9K9SM03xmJoojZe3k1cf4Y6YvHrQqZjYjkJxUO5f83s1BOeF OyaiwiOrYhGPL1A4y40tywCr6cH+TJAi0bjO4n/jxQ/Be7cfGwccFq+D0kIaoD5B8uqU oCsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=NGMho5oN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g12-v6si7385170pfh.346.2018.07.22.18.59.25; Sun, 22 Jul 2018 18:59:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=NGMho5oN; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731318AbeGWC6J (ORCPT + 31 others); Sun, 22 Jul 2018 22:58:09 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:37042 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731059AbeGWC6I (ORCPT ); Sun, 22 Jul 2018 22:58:08 -0400 Received: by mail-pg1-f193.google.com with SMTP id n7-v6so11051378pgq.4 for ; Sun, 22 Jul 2018 18:59:22 -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=A1OqVoZAh5Xl0rWEI6oRjLgOW69kgPoUkzG/O/9JyGg=; b=NGMho5oNU0sE4qV10nbpz5y3r5YofIIe50EThWfDdQjHJMZlrMEFY90K7dYQWqHXxV Qh0nh3+tX2xghAHqx/FB44jlwZT5daZ96QijBVA5BP8D4aeAnGZ8H2IoXtwqMxzxxU8J 9XAeiQwgbJd3sGg5UKoYvGUKRUyuc6QE5BVKk= 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=A1OqVoZAh5Xl0rWEI6oRjLgOW69kgPoUkzG/O/9JyGg=; b=F/tCSSp/MkySBXBT6yv2bIWLJx6odj/KwVzZQiRKol++afk89H9B8ijxbLaVGqiQ7w lLsKE01qm5dy43JheGUxh2coGjydinqZgamYMZol24uncpmSv56gzbJnFQJ4S/yXXjzA Ujb6VtohsFzkm5Ex/ARW2Kh7Arm9hMAe4//LVLFIMwMZfIzOoKBN6nOoOCWUGbA5SgVr D/qsfO8Qgx4SbIoJvBawa5HUL9M3DNLytJA6oslRHYiqf2vSD0/SywtdX4nu/GzyBMex DxrTijj6XyViM1wfl586+gSorCgiT1fdPBmt0AGxSuyRpshyXafDlVRz1m3P/ywtyy+N 28cw== X-Gm-Message-State: AOUpUlErftJV8XBXGjeThI9ytp50lqhsChV5mLNsBJd7b1XhFZLoCE01 Wqnsx9O2yvrh1p0C1X5is98+dA== X-Received: by 2002:a63:af14:: with SMTP id w20-v6mr10746599pge.47.1532311162129; Sun, 22 Jul 2018 18:59:22 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id m26-v6sm10000028pfi.102.2018.07.22.18.59.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jul 2018 18:59:21 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, rjw@rjwysocki.net, lenb@kernel.org, ard.biesheuvel@linaro.org Cc: tbaicar@codeaurora.org, bhsharma@redhat.com, dyoung@redhat.com, james.morse@arm.com, mark.rutland@arm.com, al.stone@linaro.org, graeme.gregory@linaro.org, hanjun.guo@linaro.org, lorenzo.pieralisi@arm.com, sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, AKASHI Takahiro Subject: [PATCH v4 2/5] drivers: acpi: add dependency of EFI for arm64 Date: Mon, 23 Jul 2018 10:57:29 +0900 Message-Id: <20180723015732.24252-3-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180723015732.24252-1-takahiro.akashi@linaro.org> References: <20180723015732.24252-1-takahiro.akashi@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org As Ard suggested, CONFIG_ACPI && !CONFIG_EFI doesn't make sense on arm64, while CONFIG_ACPI and CONFIG_CPU_BIG_ENDIAN doesn't make sense either. As CONFIG_EFI already has a dependency of !CONFIG_CPU_BIG_ENDIAN, it is good enough to add a dependency of CONFIG_EFI to avoid any useless combination of configuration. This bug, reported by Will, will be revealed when my patch series, "arm64: kexec,kdump: fix boot failures on acpi-only system," is applied and the kernel is built under allmodconfig. Signed-off-by: AKASHI Takahiro Suggested-by: Ard Biesheuvel --- drivers/acpi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.18.0 diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index b533eeb6139d..15ab1daaa808 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -6,7 +6,7 @@ menuconfig ACPI bool "ACPI (Advanced Configuration and Power Interface) Support" depends on !IA64_HP_SIM - depends on IA64 || X86 || ARM64 + depends on IA64 || X86 || (ARM64 && EFI) depends on PCI select PNP default y if (IA64 || X86) From patchwork Mon Jul 23 01:57:30 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 142528 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp5522670ljj; Sun, 22 Jul 2018 18:59:40 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfl3TF7JSL7XrEV9ojIykEGAcKMkZaNyWN4CWMt8KVf+DtxAXPaCS5iYM4BA99xojJY146F X-Received: by 2002:a63:161a:: with SMTP id w26-v6mr10602391pgl.257.1532311180157; Sun, 22 Jul 2018 18:59:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532311180; cv=none; d=google.com; s=arc-20160816; b=ZJQ51TBDIprxt36iYvOzhyefUWp5w2FXd5+apdHPprThL038WmxDh1ltKIMb5aJaST r+82ux3Gz7ZxMEw7XzwHI4eOf24bDl+KgUyQQUl4YL4uFYeTw/j7ywc2szO2X9G8L5gn vvBVQAyJ4k6dL3SdX+joTlLgo2AIfAYZwdBf7OdvugiZiXD81vUoEUPbxbJZJoKfY5A9 xO4ZT3uX0qrHfasUd0e37bA6r++BnHa+n2LTQzMfg3BQtARTPesEebVQfkToW3wDxQxV xIeT1zzVS1/B1yQ1+jcB/tSjkc9zNFjRRGk9y4pqkFQkrfifxwJsccdxOzj7dTPfE8IY HzGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=erM0Z9H4UEy3rQv1/bN5wC7X6sLU17kati65NrFno1I=; b=kJ+lX5pqYFxxh9mA5kgeoOukqVFA8Ms2Me2rwR3+M3AiJIHuNO2XL3sjY894dnwo9S 4wJge2yCA+S1JR2NZtHU7FoZ0oD6369n5+7hAifqu0xYtJI2KYayQhO0TRhjaRbqz2so NJPPi4z4zvC9+uZocMItQJ7FMkNd9n0Z27CosSDHsyNIeT4iQXU/AR14LbWroxPteUhs vfFpP+V7g1zKd4n7QNhSC/2LU4WnTo0JDei6sMaOZx9ER+jhuuZhjdGo84UYgP9ZL9xp DNFdTqI4GmLrRCHyctDH1zd3mRocoWvOU+bR+i2dNawsxAUjx0+njU+/rThplab3etUJ MYCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=TBTOJQLk; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f4-v6si7099710plo.226.2018.07.22.18.59.39; Sun, 22 Jul 2018 18:59:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=TBTOJQLk; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387722AbeGWC6Y (ORCPT + 31 others); Sun, 22 Jul 2018 22:58:24 -0400 Received: from mail-pl0-f67.google.com ([209.85.160.67]:46609 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731059AbeGWC6Y (ORCPT ); Sun, 22 Jul 2018 22:58:24 -0400 Received: by mail-pl0-f67.google.com with SMTP id t17-v6so4986923ply.13 for ; Sun, 22 Jul 2018 18:59:37 -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=erM0Z9H4UEy3rQv1/bN5wC7X6sLU17kati65NrFno1I=; b=TBTOJQLkajO3HY6BXZarrvI5rygueAf02u7zvXLiL8oTEfyaCJiEWTAKkFQD5siKva mwaNxKr1ko7O/hpoL0Yf46+dJ/Gmq4FUsvC+B1nuuSBCRmjKi15MRKmf61rtoDX8JMnh nAAee1TLGfgJeNxcajORbEOx9nj83BlAi5ICU= 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=erM0Z9H4UEy3rQv1/bN5wC7X6sLU17kati65NrFno1I=; b=uGU//AUicRI//PR+UpxHnK+g9mXaOQAQjNqOAGxjZ7Dq+O95FBZrvwTv5LGmTkeAzd DYeU6RelqMHh/HoSPWUy5sr1tWepi+ZrNfx3ZBWOzNacC0tjhGKmGZEAB7p0bkgTOAB9 P0z3xHvqnxyClPog6WiFgAJEL8z9RXN3d5pZyKECBsGuSDpEhomwZn7K/8aYGewz1LWJ QD6jdMGUbCZCdRi7igPQluHMopQNGlI/nbDzpRiIinJe+OHsDpgOfqIIFxd42PJjnz+r csUEe2je3oC+jAd0P+QHWAXnJfqjWBZ2S/P6/1SXkena+42Wyi0fez2D+q5tmzFrTz40 1a4g== X-Gm-Message-State: AOUpUlHv+h2IixoNMw+XYUpW306kzl6eNAtu0+pLxT7uloFHWxuu6TqL a7WTynPj0Lt+ABXOEFcIN+6Jsg== X-Received: by 2002:a17:902:583:: with SMTP id f3-v6mr11083324plf.115.1532311176843; Sun, 22 Jul 2018 18:59:36 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id h190-v6sm15115682pge.85.2018.07.22.18.59.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jul 2018 18:59:36 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, rjw@rjwysocki.net, lenb@kernel.org, ard.biesheuvel@linaro.org Cc: tbaicar@codeaurora.org, bhsharma@redhat.com, dyoung@redhat.com, james.morse@arm.com, mark.rutland@arm.com, al.stone@linaro.org, graeme.gregory@linaro.org, hanjun.guo@linaro.org, lorenzo.pieralisi@arm.com, sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org Subject: [PATCH v4 3/5] efi/arm: preserve early mapping of UEFI memory map longer for BGRT Date: Mon, 23 Jul 2018 10:57:30 +0900 Message-Id: <20180723015732.24252-4-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180723015732.24252-1-takahiro.akashi@linaro.org> References: <20180723015732.24252-1-takahiro.akashi@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Ard Biesheuvel The BGRT code validates the contents of the table against the UEFI memory map, and so it expects it to be mapped when the code runs. On ARM, this is currently not the case, since we tear down the early mapping after efi_init() completes, and only create the permanent mapping in arm_enable_runtime_services(), which executes as an early initcall, but still leaves a window where the UEFI memory map is not mapped. So move the call to efi_memmap_unmap() from efi_init() to arm_enable_runtime_services(). Signed-off-by: Ard Biesheuvel --- drivers/firmware/efi/arm-init.c | 1 - drivers/firmware/efi/arm-runtime.c | 2 ++ 2 files changed, 2 insertions(+), 1 deletion(-) -- 2.18.0 diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c index b5214c143fee..388a929baf95 100644 --- a/drivers/firmware/efi/arm-init.c +++ b/drivers/firmware/efi/arm-init.c @@ -259,7 +259,6 @@ void __init efi_init(void) reserve_regions(); efi_esrt_init(); - efi_memmap_unmap(); memblock_reserve(params.mmap & PAGE_MASK, PAGE_ALIGN(params.mmap_size + diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c index 5889cbea60b8..59a8c0ec94d5 100644 --- a/drivers/firmware/efi/arm-runtime.c +++ b/drivers/firmware/efi/arm-runtime.c @@ -115,6 +115,8 @@ static int __init arm_enable_runtime_services(void) return 0; } + efi_memmap_unmap(); + if (efi_runtime_disabled()) { pr_info("EFI runtime services will be disabled.\n"); return 0; From patchwork Mon Jul 23 01:57:31 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 142529 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp5522764ljj; Sun, 22 Jul 2018 18:59:48 -0700 (PDT) X-Google-Smtp-Source: AAOMgpekZ8+2Ud9ojQNpCHei+go+6cUWrz3weELGWK/fj44lv2Xj7Ia1qfPoo33lsvM354Pjqd7e X-Received: by 2002:a65:5245:: with SMTP id q5-v6mr10239506pgp.67.1532311188558; Sun, 22 Jul 2018 18:59:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532311188; cv=none; d=google.com; s=arc-20160816; b=CaoXdslfZLqZYm0MlXe5od193u1uDl3WHdBvDSrNHNX+7ZakLM3Qu74IbEzgdcGMnN Zuy+QCczDTSHa9iNbeGsULtJ2iMokvcWGdWTWROCPj762/9/GagXg4L0t5f8hdr+7RpJ bepAb/bcE15ITGE/qxGqMURWM7FgoYNRVBCWWeRT+oAQN8eDUr/9Ae0m+4aVW9EIciZl 62bl2SzaAsnkOVA/YuXIZJLO73O8W602LwThiTjJWXbtUN78glpNuE5oGm5ThTOTUAPf DsJmS+deSHobstKXY0wWEWbLGJR0eGoVkP2DgKcBieXpnCvUNhUnlGbSbmFgtZhV60Il tD0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=GtIoJieKMHTN394dMOednMEC4qx4H0+B96ztFdyM5HA=; b=Hu2llyg/9iINZI+rmKhxFzs7i2AdBrHUl5bE571GOkwe80+rcW/qQm49KTrv70Oy8v qVqU6yC3Olg854RAMX8DS6TBWanV8ropBpaIELxQ/tjLE8Z5cpn+BEDET7H8a1j3U3tC U4jcYLyl2bUigL0G7QBfDm+UUqfqVVc3QOTSoupiYlwaBeBn81QFn7JEhinMLf71uRot CBDz1i9ThHcUgrvI4w/KvXYQpGL1p33xSDhlFATDt259n5d3zGYrOwTjaXeuMWOVZ5QQ HueDsgGGw9OehAWeCSsMffwAnGK2cxEOYfv5oaaIM+2WfpWPMIXQhAnCCAQgQTVewTrY UHpw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=AoWFjrqT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f34-v6si7389466plf.495.2018.07.22.18.59.48; Sun, 22 Jul 2018 18:59:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=AoWFjrqT; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387775AbeGWC6c (ORCPT + 31 others); Sun, 22 Jul 2018 22:58:32 -0400 Received: from mail-pg1-f196.google.com ([209.85.215.196]:33462 "EHLO mail-pg1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387727AbeGWC6c (ORCPT ); Sun, 22 Jul 2018 22:58:32 -0400 Received: by mail-pg1-f196.google.com with SMTP id r5-v6so11060990pgv.0 for ; Sun, 22 Jul 2018 18:59:45 -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=GtIoJieKMHTN394dMOednMEC4qx4H0+B96ztFdyM5HA=; b=AoWFjrqTENdZ9sLR9tvk1DXtMK9FYxuVEAVx/sMtK6DtxQQP0xrnHfemjwcM4cMMNk GCBLIkc+Vmd6T8VbZxCOrxbZpA3z0bYgz+SzuGUilDfWEtTsBCyvrj1zo1j4cBD/2JtH XwlZXgHsekdRhkURfYmzIZ3JQpB832BHynTqw= 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=GtIoJieKMHTN394dMOednMEC4qx4H0+B96ztFdyM5HA=; b=eGpXIxNW+oVYhhnTY6QgGgLXcXfvp+3qplrmdRWyZEy6dq7cTpzozLa08TO3P5Ylvg EXCpd73aYWwpTo8WDMN2o5BXw2JxmD0ANP+Znqg+HgOYwrT2pAMjdnS8jHz+ruO+jDjd 3Xacp/R9VB3ElU6SA4eJU1zhiqnJCLwrA8W43+S87T0qzyQQvttxG9qkSNHp7f3hhdsy 3YO9TTv6RHdQSP3h1nt1x4zjH4nmr/4vZc4o6qqS4FkPkD0+nT617jk5mNMls+ZX+prY qSWSJzO0dscZhqAAjYOuZ6wZPmlf3yecSoNbEyIVnKBHfIIWJ2G9fTslRiQlD4bjmeDR ErZQ== X-Gm-Message-State: AOUpUlEGbRjmnb3PHkipL26RlOKJ1Jy2WXs33/StUg+KYuwchKtww7gn ebdsO233XBbZKBtg9sQqu0i0JA== X-Received: by 2002:a62:b40c:: with SMTP id h12-v6mr11414833pfn.18.1532311185039; Sun, 22 Jul 2018 18:59:45 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id a134-v6sm8384082pfa.158.2018.07.22.18.59.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jul 2018 18:59:44 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, rjw@rjwysocki.net, lenb@kernel.org, ard.biesheuvel@linaro.org Cc: tbaicar@codeaurora.org, bhsharma@redhat.com, dyoung@redhat.com, james.morse@arm.com, mark.rutland@arm.com, al.stone@linaro.org, graeme.gregory@linaro.org, hanjun.guo@linaro.org, lorenzo.pieralisi@arm.com, sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, AKASHI Takahiro Subject: [PATCH v4 4/5] efi/arm: map UEFI memory map even w/o runtime services enabled Date: Mon, 23 Jul 2018 10:57:31 +0900 Message-Id: <20180723015732.24252-5-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180723015732.24252-1-takahiro.akashi@linaro.org> References: <20180723015732.24252-1-takahiro.akashi@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Under the current implementation, UEFI memory map will be mapped and made available in virtual mappings only if runtime services are enabled. But in a later patch, we want to use UEFI memory map in acpi_os_ioremap() to create mappings of ACPI tables using memory attributes described in UEFI memory map. See the following commit: arm64: acpi: fix alignment fault in accessing ACPI tables So, as a first step, arm_enter_runtime_services() is modified, alongside Ard's patch[1], so that UEFI memory map will not be freed even if efi=noruntime. [1] https://marc.info/?l=linux-efi&m=152930773507524&w=2 Signed-off-by: AKASHI Takahiro Reviewed-by: Ard Biesheuvel --- drivers/firmware/efi/arm-runtime.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) -- 2.18.0 diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c index 59a8c0ec94d5..a00934d263c5 100644 --- a/drivers/firmware/efi/arm-runtime.c +++ b/drivers/firmware/efi/arm-runtime.c @@ -117,6 +117,13 @@ static int __init arm_enable_runtime_services(void) efi_memmap_unmap(); + mapsize = efi.memmap.desc_size * efi.memmap.nr_map; + + if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) { + pr_err("Failed to remap EFI memory map\n"); + return 0; + } + if (efi_runtime_disabled()) { pr_info("EFI runtime services will be disabled.\n"); return 0; @@ -129,13 +136,6 @@ static int __init arm_enable_runtime_services(void) pr_info("Remapping and enabling EFI services.\n"); - mapsize = efi.memmap.desc_size * efi.memmap.nr_map; - - if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) { - pr_err("Failed to remap EFI memory map\n"); - return -ENOMEM; - } - if (!efi_virtmap_init()) { pr_err("UEFI virtual mapping missing or invalid -- runtime services will not be available\n"); return -ENOMEM; From patchwork Mon Jul 23 01:57:32 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 142530 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp5522849ljj; Sun, 22 Jul 2018 18:59:58 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcNhJoQXaeHKj3LrlTQYl1a9Bb1wsGKV+6mJG2eYFfJGglYApUyuPW9VL3mnaQyuu4FynT6 X-Received: by 2002:a17:902:bb08:: with SMTP id l8-v6mr7056166pls.246.1532311197964; Sun, 22 Jul 2018 18:59:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532311197; cv=none; d=google.com; s=arc-20160816; b=UKsa72kTGS7uEclXYJ723ishJghgM8cva4eyPBXfb7wYdN/pVjTiBmyUiBO7ZOZhjr i/P3+8nY0H0GfCrFUKOaSs5SrW2ynYTDQam3qdir7LxbLbGZShRs8af85RnMdlCHHtHX pXCW5La7a5Jigg+mtwEjYE36ClaaelQ/NZHwiAgorOcDPSXG3gtUEEiYuw+RNaSQWCGq hge5rO3y6TJCCwwrc1oOhkk7JPKpwyPPuVCWzOTBM5iUTS5x1vxzhquu7366oxZWEdMO KVVIjg52qMa5DpZopqB/8aeyRAt+t0OXEvFiE7tq3PnhNyNa1cs2CET61MrXli6Qx0x2 kjQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=aiI32IJC87n1yrLeU9zsbi8Z298a1EB8XLfokLEiOx0=; b=QaIpvM9QURPEUF4A4jK7Avvq/KArXZhKS730qZwMHWhtk0GXgMJwdiASj2asywwqVg zPYdehPPKu2aYG5tceaenjw/R9rVNDeWuVLmde6qazFEswDxECZD1tDtZgPduusvkxgm wU2ZZXz5hYOztnR12YCQ871xZhCcTkjwoe9HyPuKLNqCA2unfDDhUoB9qfNxatBAFflQ FzYHMVJPJvr+A1bXk35nhUV56c3rYe7rgshbCCZc5N0Q8/xyt4PNtnDYMO6M90RZ7w4Z aiqVTfdAJdjP7BoP4tRpMk/RHJtrWAwFO8Be6VtxZe4kGTwvy0N7jwpjYwqW7DlUeg1S MPIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LCQUREp9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b5-v6si7221580ple.417.2018.07.22.18.59.57; Sun, 22 Jul 2018 18:59:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LCQUREp9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387802AbeGWC6l (ORCPT + 31 others); Sun, 22 Jul 2018 22:58:41 -0400 Received: from mail-pg1-f194.google.com ([209.85.215.194]:45031 "EHLO mail-pg1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387689AbeGWC6l (ORCPT ); Sun, 22 Jul 2018 22:58:41 -0400 Received: by mail-pg1-f194.google.com with SMTP id r1-v6so11058064pgp.11 for ; Sun, 22 Jul 2018 18:59:54 -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=aiI32IJC87n1yrLeU9zsbi8Z298a1EB8XLfokLEiOx0=; b=LCQUREp94LJj/UbwQ1WlvKHuiSLfHdIhXSELJpx7EaJq4upi0yxteLLk1mc7kzaU3x OLoD9kzQuzd4FtjdgjWKRwpHM3XgUzE7JeHmskIkS9XID4FzDKDaG5PEcjB8ApEO39o0 upnfD+C4KiXUeE8Kk1uKBraH1mqikV89HcYLM= 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=aiI32IJC87n1yrLeU9zsbi8Z298a1EB8XLfokLEiOx0=; b=TRKD3+qXbnxwDO+KnajzYJhdXwXw2t0ZlMnUPdAVVOlLL9t46s6h5a8VPszZzKV6BX t3hSX2507pgLvsKM76kY7KIl2MhSCg9yhg9YKlA1S9bIAEGA5L/c/Iw56Nu5cy4FFu6D x14oa3utatQkxubJ2f5E/zT++YVefRE2fb8ZpVnRzCUlySiRx7x1GUIzYWawc1qQjXgV rEMavYdAVvC4JfCVOJfOarVCzd2diDd8N/7plV8Me+B9Rrw+t/I/sgLJ979WoCuAplfE RehT6JdtnuebVS4msGRuFFnbB76oCu5ORE8NXpL/J/9rjm1WBq7ibTeNM35a0YdrYuMY 2hVw== X-Gm-Message-State: AOUpUlEoh3HoiQI1/572Tmyo7Kv3lR1rbX0tsPHE73YyC9Sx+a9lAXFC 5UwrAe+3qmH1muKQecGGAesR6w== X-Received: by 2002:a63:f414:: with SMTP id g20-v6mr10308718pgi.407.1532311193979; Sun, 22 Jul 2018 18:59:53 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id a11-v6sm13539222pfl.66.2018.07.22.18.59.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Jul 2018 18:59:53 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, rjw@rjwysocki.net, lenb@kernel.org, ard.biesheuvel@linaro.org Cc: tbaicar@codeaurora.org, bhsharma@redhat.com, dyoung@redhat.com, james.morse@arm.com, mark.rutland@arm.com, al.stone@linaro.org, graeme.gregory@linaro.org, hanjun.guo@linaro.org, lorenzo.pieralisi@arm.com, sudeep.holla@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kexec@lists.infradead.org, AKASHI Takahiro Subject: [PATCH v4 5/5] arm64: acpi: fix alignment fault in accessing ACPI Date: Mon, 23 Jul 2018 10:57:32 +0900 Message-Id: <20180723015732.24252-6-takahiro.akashi@linaro.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180723015732.24252-1-takahiro.akashi@linaro.org> References: <20180723015732.24252-1-takahiro.akashi@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a fix against the issue that crash dump kernel may hang up during booting, which can happen on any ACPI-based system with "ACPI Reclaim Memory." (kernel messages after panic kicked off kdump) (snip...) Bye! (snip...) ACPI: Core revision 20170728 pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707 Internal error: Oops: 96000021 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1 task: ffff000008d05180 task.stack: ffff000008cc0000 PC is at acpi_ns_lookup+0x25c/0x3c0 LR is at acpi_ds_load1_begin_op+0xa4/0x294 (snip...) Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000) Call trace: (snip...) [] acpi_ns_lookup+0x25c/0x3c0 [] acpi_ds_load1_begin_op+0xa4/0x294 [] acpi_ps_build_named_op+0xc4/0x198 [] acpi_ps_create_op+0x14c/0x270 [] acpi_ps_parse_loop+0x188/0x5c8 [] acpi_ps_parse_aml+0xb0/0x2b8 [] acpi_ns_one_complete_parse+0x144/0x184 [] acpi_ns_parse_table+0x48/0x68 [] acpi_ns_load_table+0x4c/0xdc [] acpi_tb_load_namespace+0xe4/0x264 [] acpi_load_tables+0x48/0xc0 [] acpi_early_init+0x9c/0xd0 [] start_kernel+0x3b4/0x43c Code: b9008fb9 2a000318 36380054 32190318 (b94002c0) ---[ end trace c46ed37f9651c58e ]--- Kernel panic - not syncing: Fatal exception Rebooting in 10 seconds.. (diagnosis) * This fault is a data abort, alignment fault (ESR=0x96000021) during reading out ACPI table. * Initial ACPI tables are normally stored in system ram and marked as "ACPI Reclaim memory" by the firmware. * After the commit f56ab9a5b73c ("efi/arm: Don't mark ACPI reclaim memory as MEMBLOCK_NOMAP"), those regions are differently handled as they are "memblock-reserved", without NOMAP bit. * So they are now excluded from device tree's "usable-memory-range" which kexec-tools determines based on a current view of /proc/iomem. * When crash dump kernel boots up, it tries to accesses ACPI tables by mapping them with ioremap(), not ioremap_cache(), in acpi_os_ioremap() since they are no longer part of mapped system ram. * Given that ACPI accessor/helper functions are compiled in without unaligned access support (ACPI_MISALIGNMENT_NOT_SUPPORTED), any unaligned access to ACPI tables can cause a fatal panic. With this patch, acpi_os_ioremap() always honors memory attribute information provided by the firmware (EFI) and retaining cacheability allows the kernel safe access to ACPI tables. Signed-off-by: AKASHI Takahiro Reviewed-by: James Morse Reviewed-by: Ard Biesheuvel Reported-by and Tested-by: Bhupesh Sharma --- arch/arm64/include/asm/acpi.h | 23 ++++++++++++++++------- arch/arm64/kernel/acpi.c | 11 +++-------- 2 files changed, 19 insertions(+), 15 deletions(-) -- 2.18.0 diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h index 0db62a4cbce2..68bc18cb2b85 100644 --- a/arch/arm64/include/asm/acpi.h +++ b/arch/arm64/include/asm/acpi.h @@ -12,10 +12,12 @@ #ifndef _ASM_ACPI_H #define _ASM_ACPI_H +#include #include #include #include +#include #include #include @@ -29,18 +31,22 @@ /* Basic configuration for ACPI */ #ifdef CONFIG_ACPI +pgprot_t __acpi_get_mem_attribute(phys_addr_t addr); + /* ACPI table mapping after acpi_permanent_mmap is set */ static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys, acpi_size size) { + /* For normal memory we already have a cacheable mapping. */ + if (memblock_is_map_memory(phys)) + return (void __iomem *)__phys_to_virt(phys); + /* - * EFI's reserve_regions() call adds memory with the WB attribute - * to memblock via early_init_dt_add_memory_arch(). + * We should still honor the memory's attribute here because + * crash dump kernel possibly excludes some ACPI (reclaim) + * regions from memblock list. */ - if (!memblock_is_memory(phys)) - return ioremap(phys, size); - - return ioremap_cache(phys, size); + return __ioremap(phys, size, __acpi_get_mem_attribute(phys)); } #define acpi_os_ioremap acpi_os_ioremap @@ -129,7 +135,10 @@ static inline const char *acpi_get_enable_method(int cpu) * for compatibility. */ #define acpi_disable_cmcff 1 -pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr); +static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr) +{ + return __acpi_get_mem_attribute(addr); +} #endif /* CONFIG_ACPI_APEI */ #ifdef CONFIG_ACPI_NUMA diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c index 7b09487ff8fb..ed46dc188b22 100644 --- a/arch/arm64/kernel/acpi.c +++ b/arch/arm64/kernel/acpi.c @@ -18,6 +18,7 @@ #include #include #include +#include #include #include #include @@ -29,13 +30,9 @@ #include #include +#include #include -#ifdef CONFIG_ACPI_APEI -# include -# include -#endif - int acpi_noirq = 1; /* skip ACPI IRQ initialization */ int acpi_disabled = 1; EXPORT_SYMBOL(acpi_disabled); @@ -239,8 +236,7 @@ void __init acpi_boot_table_init(void) } } -#ifdef CONFIG_ACPI_APEI -pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr) +pgprot_t __acpi_get_mem_attribute(phys_addr_t addr) { /* * According to "Table 8 Map: EFI memory types to AArch64 memory @@ -261,4 +257,3 @@ pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr) return __pgprot(PROT_NORMAL_NC); return __pgprot(PROT_DEVICE_nGnRnE); } -#endif