Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1556546pxa; Thu, 6 Aug 2020 10:11:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyBnMofXaLKzUe6gGmTwZYIpKLzhDAL2ZfeNi36HCof945UNCdMmvhHUtkIctIaa+b0rEtb X-Received: by 2002:a17:906:7104:: with SMTP id x4mr5562501ejj.417.1596733904738; Thu, 06 Aug 2020 10:11:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596733904; cv=none; d=google.com; s=arc-20160816; b=JaMM9BEMxAII+oBmFCpUkzgBGqtiMTUx+RES1kV1l1Jn3Qz7I3uSMQkhyKj8fxRFG1 IUIvLAhgKCyASMPDDVIjAdsi+8rjNZwT0Nu/YoAZqG/6wZ1XBJT4Hp2msJgZJur5DrnY /o21pB4qQGs46xhfmzsuYmtf5njiZ01fr+6efqly/bZdhl5o7JVxFLslxqB15NIlDJjt sOf1F6Rb4k/jBwVC7xhdsJFkH3T8POwM6ZRjg7HbkBWoN6nZrL1Bj/9Ny06Z4Sg/3Zsq HqbedVYdss++AT/FQvtLJQikyDoNOKrko0ndRoGP7N3D8/lS/0VVPlEsGObRo6ZbZ5Nq up3w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :robot-unsubscribe:robot-id:message-id:mime-version:references :in-reply-to:cc:subject:to:reply-to:from:dkim-signature :dkim-signature:date; bh=86mczRWqEs3jdentO74wVd8eG11njrwgMiO5ym6RDSo=; b=UokmzpTIZRfT8gfybY+mMi6kw99ZV4Unrv1TUyGDhibrJE20tEu4Mw59ltZwh81lJM zSdJ3xdQGqFM0Ue9iioRASN0qXch4MzVqVtD1UxLRS0nZgYV8ZwjDktvb0GqFltWRies jNkX5FexvN6NnliW9fu3AqrgP3vT+04juDK/UYmh9e2QgBAStZQQdtE+sn6LCgeCsVWS T9a99xH+4rdL51BY5ANl8+9monQaHgim8lNEtMoMXGcCW7uU/9tBTXs2XezZLFx4H1H8 hYvZddBAmFXhjlfxwAoDjyAQGHTKdFTtrRoWd3sMKHIaJyzoKtY99EfQtxz2E7299Jxf SkFA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@linutronix.de header.s=2020 header.b=yWJ7blUf; dkim=neutral (no key) header.i=@vger.kernel.org header.s=2020e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q22si3578091edr.317.2020.08.06.10.11.22; Thu, 06 Aug 2020 10:11:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@linutronix.de header.s=2020 header.b=yWJ7blUf; dkim=neutral (no key) header.i=@vger.kernel.org header.s=2020e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729679AbgHFRKu (ORCPT + 99 others); Thu, 6 Aug 2020 13:10:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46492 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730224AbgHFRKJ (ORCPT ); Thu, 6 Aug 2020 13:10:09 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 11CF9C061574; Thu, 6 Aug 2020 10:10:09 -0700 (PDT) Date: Thu, 06 Aug 2020 17:10:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1596733807; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=86mczRWqEs3jdentO74wVd8eG11njrwgMiO5ym6RDSo=; b=yWJ7blUfakNJChOlS7S+NMPzx89Opw8aiCjTycbxt3Or0tg883CZ536WsTkNPMfJUCKtwR 0gm56xu/chI0hcIxBHcEMM6il3qX65YKQfyE4xMPoI+ttkui2g5c7N3O8tWovyyGLHF8n0 QmSBelUbcoyYSTQ5M1XpeJmdKx1HJQrRgRwviJBoQy1SNlgIl68Gq/dB6HqsCbaqooDS/v w33SkGWpLDL2vCGn08xPCPRXXBJISVV5p++hFy+Zim8VNTVPs1crLWJmL1bWTt8l5U6T7m eE07W1buuQPZNhertQU/if9VBwS1FU2g4ftNVzM3vwIo18S3Nm9keWvYILl9AA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1596733807; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=86mczRWqEs3jdentO74wVd8eG11njrwgMiO5ym6RDSo=; b=i8BPkqJpWYMyMJv+JvWIV6hZegrmcff66znzk2VqL5WVQKeXaFPbsjlvVr15bc3dKF9OWQ 1x5DPk7r+5TOwXAg== From: "tip-bot2 for Lianbo Jiang" Reply-to: linux-kernel@vger.kernel.org To: linux-tip-commits@vger.kernel.org Subject: [tip: x86/urgent] kexec: Improve & fix crash_exclude_mem_range() to handle overlapping ranges Cc: Lianbo Jiang , Ingo Molnar , Dave Young , x86 , LKML In-Reply-To: <20200804044933.1973-3-lijiang@redhat.com> References: <20200804044933.1973-3-lijiang@redhat.com> MIME-Version: 1.0 Message-ID: <159673380690.3192.7724116309741101054.tip-bot2@tip-bot2> Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 12e4e432ac4d65020ba85037da06f2c886188e4f Gitweb: https://git.kernel.org/tip/12e4e432ac4d65020ba85037da06f2c886188e4f Author: Lianbo Jiang AuthorDate: Tue, 04 Aug 2020 12:49:32 +08:00 Committer: Ingo Molnar CommitterDate: Thu, 06 Aug 2020 15:25:58 +02:00 kexec: Improve & fix crash_exclude_mem_range() to handle overlapping ranges The crash_exclude_mem_range() function can only handle one memory region a time. It will fail in the case in which the passed in area covers several memory regions. In this case, it will only exclude the first region, then return, but leave the later regions unsolved. E.g in a NEC system with two usable RAM regions inside the low 1M: ... BIOS-e820: [mem 0x0000000000000000-0x000000000003efff] usable BIOS-e820: [mem 0x000000000003f000-0x000000000003ffff] reserved BIOS-e820: [mem 0x0000000000040000-0x000000000009ffff] usable It will only exclude the memory region [0, 0x3efff], the memory region [0x40000, 0x9ffff] will still be added into /proc/vmcore, which may cause the following failure when dumping vmcore: ioremap on RAM at 0x0000000000040000 - 0x0000000000040fff WARNING: CPU: 0 PID: 665 at arch/x86/mm/ioremap.c:186 __ioremap_caller+0x2c7/0x2e0 ... RIP: 0010:__ioremap_caller+0x2c7/0x2e0 ... cp: error reading '/proc/vmcore': Cannot allocate memory kdump: saving vmcore failed In order to fix this bug, let's extend the crash_exclude_mem_range() to handle the overlapping ranges. [ mingo: Amended the changelog. ] Signed-off-by: Lianbo Jiang Signed-off-by: Ingo Molnar Acked-by: Dave Young Link: https://lore.kernel.org/r/20200804044933.1973-3-lijiang@redhat.com --- kernel/kexec_file.c | 35 +++++++++++++++++++++++------------ 1 file changed, 23 insertions(+), 12 deletions(-) diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index 09cc78d..5cc2c47 100644 --- a/kernel/kexec_file.c +++ b/kernel/kexec_file.c @@ -1157,24 +1157,26 @@ int crash_exclude_mem_range(struct crash_mem *mem, unsigned long long mstart, unsigned long long mend) { int i, j; - unsigned long long start, end; + unsigned long long start, end, p_start, p_end; struct crash_mem_range temp_range = {0, 0}; for (i = 0; i < mem->nr_ranges; i++) { start = mem->ranges[i].start; end = mem->ranges[i].end; + p_start = mstart; + p_end = mend; if (mstart > end || mend < start) continue; /* Truncate any area outside of range */ if (mstart < start) - mstart = start; + p_start = start; if (mend > end) - mend = end; + p_end = end; /* Found completely overlapping range */ - if (mstart == start && mend == end) { + if (p_start == start && p_end == end) { mem->ranges[i].start = 0; mem->ranges[i].end = 0; if (i < mem->nr_ranges - 1) { @@ -1185,20 +1187,29 @@ int crash_exclude_mem_range(struct crash_mem *mem, mem->ranges[j].end = mem->ranges[j+1].end; } + + /* + * Continue to check if there are another overlapping ranges + * from the current position because of shifting the above + * mem ranges. + */ + i--; + mem->nr_ranges--; + continue; } mem->nr_ranges--; return 0; } - if (mstart > start && mend < end) { + if (p_start > start && p_end < end) { /* Split original range */ - mem->ranges[i].end = mstart - 1; - temp_range.start = mend + 1; + mem->ranges[i].end = p_start - 1; + temp_range.start = p_end + 1; temp_range.end = end; - } else if (mstart != start) - mem->ranges[i].end = mstart - 1; + } else if (p_start != start) + mem->ranges[i].end = p_start - 1; else - mem->ranges[i].start = mend + 1; + mem->ranges[i].start = p_end + 1; break; } @@ -1243,7 +1254,7 @@ int crash_prepare_elf64_headers(struct crash_mem *mem, int kernel_map, * kexec-tools creates an extra PT_LOAD phdr for kernel text mapping * area (for example, ffffffff80000000 - ffffffffa0000000 on x86_64). * I think this is required by tools like gdb. So same physical - * memory will be mapped in two elf headers. One will contain kernel + * memory will be mapped in two elf headers. One will contain kernel * text virtual addresses and other will have __va(physical) addresses. */ @@ -1270,7 +1281,7 @@ int crash_prepare_elf64_headers(struct crash_mem *mem, int kernel_map, ehdr->e_ehsize = sizeof(Elf64_Ehdr); ehdr->e_phentsize = sizeof(Elf64_Phdr); - /* Prepare one phdr of type PT_NOTE for each present cpu */ + /* Prepare one phdr of type PT_NOTE for each present CPU */ for_each_present_cpu(cpu) { phdr->p_type = PT_NOTE; notes_addr = per_cpu_ptr_to_phys(per_cpu_ptr(crash_notes, cpu));