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: 141353 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp2054471ljj; Sun, 8 Jul 2018 17:07:17 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfR9zIcdxWGvB6q68WSCt/gW1n7uuENru74UyDbW6kpZBjouP1jYLvjvtgHUldYXojnSvl1 X-Received: by 2002:a63:ec14:: with SMTP id j20-v6mr16645158pgh.28.1531094837748; Sun, 08 Jul 2018 17:07:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531094837; cv=none; d=google.com; s=arc-20160816; b=y2RORaMtHS+/Y49tIRTt3n2nPNpSNltimEzg4JNDlH7ENSO9rLDmnDpfcpp7D2w9RR 9F+BSbmwWIW1ftztdqrZW/Otm+lQ4mUH5xwq28i4Gb9qQIPn3fX3/s8VSW92NinH+sW9 9xgmqPsd+YgTKAVsXbS5eM+kQHpD3Y8mWiYh3ej8SoSO3RytaQ4G6AoapwuJmG7BBbfD Wyts0cgh9Pmw9ilbH1hx1PsMS7WVOGNrdHn2pZHnVp7GzBAGdEJAUd8mI1j1oqi7So4R EFGddfSOy42e8sXFTMyR2R3TKBfceDqbO1ZYGmeIHUtsbbhfxthghzrtvadYH0qJjKKQ cFyQ== 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=F9qL97WIJTDKar0RATFRGa32DomSlp6yFEb0hpSLUU4=; b=KEKUPuQCqsRshO6Vo+/3VYTmzhzxBIuP/rWBbJwBH2TbDMDJKxXcGdXZQ8fRCKt6cQ 5nDU08vnF/js7RMIk5c8jGNXGEgeWHqnRiqtFFJXLMkooWonLUoTZB5VCckQ9omr84Yq IDtqcxT6Bb5lprVyLMzbaa4Fx5QUpMhGBXlZiaiDsJeuO30rQs00PjpDeJq6zcl32nBI 8hF9M72lBuNaec3seESwnlGHimjQaIOS48ql7f6YUpRP45qdlgfeMJSwzzGhgaI1JQKn edB2E5eCMrwKu2a4k+fFuGshfZA1sz++E5AUczQHe8SFL9Ip+oM7Do+P1sct2B7ktk/I q5Vw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=kd2ptLTQ; 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 h126-v6si10906751pgc.429.2018.07.08.17.07.17; Sun, 08 Jul 2018 17:07:17 -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=kd2ptLTQ; 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 S933423AbeGIAHP (ORCPT + 28 others); Sun, 8 Jul 2018 20:07:15 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:40925 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932942AbeGIAHO (ORCPT ); Sun, 8 Jul 2018 20:07:14 -0400 Received: by mail-pf0-f194.google.com with SMTP id z24-v6so12320326pfe.7 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=CqJB7B4gkqs+a53NkpHJcIOLPUjZ3ecIa+g/KYn6faFhN+kbZfK9HN266TBFDrrDyN 9zfpAvT7VmAXRblLw7CoaUSSjh51GfHtweXUskSllGJz8hidbEDlbXij/ErWGEAAp1Ns FtrqQjqc3vhV8haGDPXV7vYh/x3cjPzaI81/e5KVytFu4kKvypAawTUCKpmwTY0ucaA+ 8tgYBYliB1/jjLyZAcKgaIDEjxT+3VUFaRrwq14E+b30Y/4/eefbNEg+hEiVWMQIHbsP Z+LIqHLKSaFXfUWak1ZHHiYy1Hd3/khZWScRgFvi8UJPVAkOh32MlYPiCzbDOfI65ucw nIsA== X-Gm-Message-State: APt69E03R//4CjxG7zkS59ZooK+UoEhQYpgvO/iPcF64gEJDZGtMYa8I BiLZlHdo+l/Ugw26QrO01ynu/g== 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 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 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> 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.17.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 9 00:07:49 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 141354 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp2054630ljj; Sun, 8 Jul 2018 17:07:30 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeZXTcLWHwXxOdqXeaJ+XlDqhLqlBrdlGvDc8oJMWrYkTrASlO9IFeAW1zjzvQSlA+xvfCV X-Received: by 2002:a63:6e07:: with SMTP id j7-v6mr17271462pgc.251.1531094850485; Sun, 08 Jul 2018 17:07:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531094850; cv=none; d=google.com; s=arc-20160816; b=Jx+ul/VuE6OUp/iXXvaYloeBDDI2M8kOU8cKHJHMO+akZNQpuT5/CcaeKaTbZb+TlB wTDSa0yv9WdVIO2UruLCW2lkQ0r2J+ePPRzOLsXEuDnnZDd2AugU2lCJM+Q0jQATCMR/ XKFlgfCmdspj9mQlfI3R1mc+Mkw+HYQ7ibgIi8ZXWwQeU899UWokxN0Xl+lyNBG9oca3 YV8M7ZFOSyUuC2hFTriyQ8VhujSoVi8cw69kKgduo4vHiyvtwJtC0bAIZmlmzdYgonUx P5uSPhvbpIxGe1KOUJnnoPv2LXO6t3wdTO41R0j3M4fxvetO8++meLwvV2DVIg9ssCFN ue4A== 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=6svwEjRZKw/fRIHWE4svwtkCI66G0b2U5AUFtaL5oWI=; b=GagMYv61MsPwDP0eY93s2WJPYnYPkx0MNn2bsdDGpozzw8lKdkjREBWYfbYbH3qUMD 7Of46FeLTfH7xiz66sNfLCLWbojyNPZERRiJ7H7YuqCqRmxZ/cTn9hP0UkBsKjUCJUyv awHWMcGG1RtY2llNN9bkTrWJIgKE9sFBNG3QWziIFY5QwowXi94rPcdY+hJyhXBA64CA kWUv6NrODWCYy74O/TO0DNSaJGc/uBHU2ud7kpg+eM3lnhYjbdiIbtFV8sJw9umb2lPT NOPaXmqBK3ccG4iS99CBnfnS6wYSpKSlQwYwm26G28bBqDSeN+Mo9IP2hDGefBgL6kQK +1DQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=aVO9AxUa; 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 1-v6si13339670plu.282.2018.07.08.17.07.30; Sun, 08 Jul 2018 17:07:30 -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=aVO9AxUa; 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 S933475AbeGIAH2 (ORCPT + 28 others); Sun, 8 Jul 2018 20:07:28 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:46242 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932942AbeGIAH1 (ORCPT ); Sun, 8 Jul 2018 20:07:27 -0400 Received: by mail-pf0-f193.google.com with SMTP id l123-v6so12307688pfl.13 for ; Sun, 08 Jul 2018 17:07:27 -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=6svwEjRZKw/fRIHWE4svwtkCI66G0b2U5AUFtaL5oWI=; b=aVO9AxUa84C7u9yYJC2JIvknxGTWlFrP3nLGGLmn+vzBj9YBWrAOxTM3jsnL1Npp45 nNvzR39Yp4ZU9xrjRqBSrzxSNm2k4yNEGNYwuJI2rfY41LNeYPZmhUNQ1IQL9X6YSnIx Kkm+cULSU/ki+V+IMYVjDzPDNC7q/dTFxCowg= 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=6svwEjRZKw/fRIHWE4svwtkCI66G0b2U5AUFtaL5oWI=; b=TKvcE3FLdgUSI3/FuIRaM6YHoGk6r1HlUYUkOHf4YR4Z7dA7ABLIJmp7YWjMqIewev dZAcK/xab5SjMNjYDAulmJqBtihiGGicqYu7+nP5ClXHqXcPrhrWPn9qeVUdxi0VORrp wtOjJs6wkbkXtUuou0I4YTHm6ZWub/rLwslMjj4EGVKqFTvun1MOXMQDlQf81o5ocN2v toH0ZCLTeNkt4d48mfQ1n0IL1y5fkSA6jIdhWDvh1xKyp8jvoqjChjvks1llXiGRQc0H 46WbT++TlJGtJTtslvtzsH9np9qN8AUx8ewNn0rvOv+kCdzzFRLbyDKVaYUKSN9aBIXH dMFQ== X-Gm-Message-State: APt69E2fWowYWZ6QmeRCzBPkkgOyaTyW6/duDquK37m7wQ/kCGijaZlU HKk85+w76gXBjhIocq4cuyp6TN8IhV8= X-Received: by 2002:a62:e30c:: with SMTP id g12-v6mr19139845pfh.25.1531094846860; Sun, 08 Jul 2018 17:07:26 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id j5-v6sm24598310pfc.56.2018.07.08.17.07.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jul 2018 17:07:26 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, 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 v3 2/3] efi/arm: map UEFI memory map even w/o runtime services enabled Date: Mon, 9 Jul 2018 09:07:49 +0900 Message-Id: <20180709000750.22172-3-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> 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.17.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 9 00:07:50 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: AKASHI Takahiro X-Patchwork-Id: 141355 Delivered-To: patch@linaro.org Received: by 2002:a2e:9754:0:0:0:0:0 with SMTP id f20-v6csp2054784ljj; Sun, 8 Jul 2018 17:07:43 -0700 (PDT) X-Google-Smtp-Source: AAOMgpepRZouwX/41fPDLBqMdORluwZPQjtYbMr0r8r0bJLJuFEmHiO4UQ9uOD/zil3mFQW7EcXW X-Received: by 2002:a17:902:42c3:: with SMTP id h61-v6mr18383368pld.319.1531094862866; Sun, 08 Jul 2018 17:07:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531094862; cv=none; d=google.com; s=arc-20160816; b=X9EHC1xzNMtXfK2FCd98+DjwkddBLVDGvZb8YfxLCainKNLiRpe+XUZzGVWIFfOQkd ZPSCknS4+nPyWr2J+OwRGIPxDJcyD56jXuCXbcUoikKtqX9/VmsqkRrbcuq+bA0cVKyf jaNZMcmWiqY14s1auJLw6iIqffMhhDHSxLm+VqsoKACi580Bgga4e8KXbO03j+3zL86Y aW6O6Omi37VJpSc94HOvB0P51BDDXeEvY4P6DScYbJsiuxSHVXOTBIr2OrOrDbhKs4g/ JC6mhRzkMRm5+u6Es4gQOYZnMs4I324avFnH3ZSExXIOs/YkMHRStZrrLahLmO3OUqks oSAg== 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=8W7o3oy86/J1tw2fkmeq5q6MVz6b0M86D1KTHsBktO0=; b=LxWT4wz3WpJuqd9JfzWVogrhDSY2eHw9bjvdQVS2NrUwrloIuXB9Ib96TZj1ELOHgB hfw9ZMCkKyOF8HXK16pFOjzrryXfz2waGM1VNmLtBqKDQ6exdPZzdRiab8eVwFaRoJil hruTSloHgvl1syDiD4lBXlnkeK4d5fMeUDZN+VwHo7cA2ck7axPKHE+yTmHldhEQYHBv 5GjLH+Na3EVwT6lNIb6tAA+/YkKBt7a4Dp6fgC0xlm6BxnmDO+SpCgrtJLVqVLJbXcJp HXzauQ6mog3QksAdzMjJFEoriMaITVyFE0aIt2eAq7y+Z3BCIMUErK9teuVgQwBxYYOo pjJw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=ViiOmf3q; 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 1-v6si13339670plu.282.2018.07.08.17.07.42; Sun, 08 Jul 2018 17:07:42 -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=ViiOmf3q; 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 S933516AbeGIAHj (ORCPT + 28 others); Sun, 8 Jul 2018 20:07:39 -0400 Received: from mail-pl0-f67.google.com ([209.85.160.67]:39868 "EHLO mail-pl0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932942AbeGIAHi (ORCPT ); Sun, 8 Jul 2018 20:07:38 -0400 Received: by mail-pl0-f67.google.com with SMTP id s24-v6so5169993plq.6 for ; Sun, 08 Jul 2018 17:07:38 -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=8W7o3oy86/J1tw2fkmeq5q6MVz6b0M86D1KTHsBktO0=; b=ViiOmf3qla3FWhgYVb1QC3TQlEDThtN0RYP1qRcmdogabGTBFgsv4XJqOBdJwhdZ4p CRp6w2AdGh50x9VMErERs2S70JeHKMt0ZTr6EYLsSyKSlYUK14JAHcCiYYqjGD329nRf W47Av0ybpacnFJQbvo7xT8/ZWxIB5+sTIQ2EA= 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=8W7o3oy86/J1tw2fkmeq5q6MVz6b0M86D1KTHsBktO0=; b=YnG3rH0wZrszxzwFOcQi3s0KPk+gBsUrmfiNE73JlZfVZmUutChI7sZD2Rnu1w+eKV TbPg+73JjkO4PWL8M9yKlBQ+blZKmHFEEwB1IFGWBcWNR4Q935W6gdCCyWIV1AM9RGUD fYpMZv31D55M2T2MJMii3C/jFTRw7KtiOr+dzPdJU/+e2AU7BcOgbGFaaEOqJE89nEMB aNAQhQf2ghdVXkhTCxdqPGso4p+E5vKnrjbCqNXxK+/YIVyboL12i+dLZhBgMSfKjqwY 5YzuunBD+4v+j8PQgyLl96eIFvkoBd3enLHAyI4ZnOm6Dqdd2zDhY71sWBKCYIgM6OLa Ia3g== X-Gm-Message-State: APt69E0imVHITd9XhgoiKg+0ywCC9EEg48TyodCwwfDGo/WIsb+9Oa9T YImRE8GQv+QIQSt7DCcU+GoB2Q== X-Received: by 2002:a17:902:9681:: with SMTP id n1-v6mr18955431plp.244.1531094857906; Sun, 08 Jul 2018 17:07:37 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id h12-v6sm20583512pfi.114.2018.07.08.17.07.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Jul 2018 17:07:37 -0700 (PDT) From: AKASHI Takahiro To: catalin.marinas@arm.com, will.deacon@arm.com, 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 v3 3/3] arm64: acpi: fix alignment fault in accessing ACPI Date: Mon, 9 Jul 2018 09:07:50 +0900 Message-Id: <20180709000750.22172-4-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> 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.17.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