Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp1297181ybg; Wed, 23 Oct 2019 13:29:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqyxfI0pzHRo7fDlOrTbpJzJ91GIFsGSGHw3b8ZgratFnLuK56Rv9qWJoPUbT/bASiBMEDsJ X-Received: by 2002:a17:906:b798:: with SMTP id dt24mr20927774ejb.210.1571862569980; Wed, 23 Oct 2019 13:29:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571862569; cv=none; d=google.com; s=arc-20160816; b=nYYzCRCwNQeia7uSX96RX0VS3+PFgsCfApNGASXv9U1g4yvu2sk6r49/PRqH5DaeVt /k+gRsKLNoAPUo5GYraqiZBEfjS+OHABplyawc37X6LGUbp31cXTz64rX3v0P3IfXVwm 2X7zwJHSaRgtL4+fkTR6I0hqJ8aNRndWOmfO5S+/jIzY5CeI2w6k4RAnm7p1TOAZ/6y1 3ZwdzhtycJRVnyy0s5lmU0F7mdnGtQRk3X1cpdFeam9O2YGks1bltvOUjNBzB1QecsUA SUIWNk2+qTTlwUxQyVWjtFbot1IJOWcYj+DMJPVKH76/K6OmBdlc3HLtKN1jkvLI0E0+ OTRg== 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:message-id:date :subject:cc:to:from:dkim-signature; bh=b5XwPGWfRLOQx/XL/lGD6w9DJuiaWtEwmYD7upyMG5M=; b=vO5OFDqbEIIPRhwa4h/pAUCldsiLKgKv6EzX2rdIcsx3uT0TonRvPm2K63lfsxc/SJ l8ru6hNy39LJEI94OjZaDOmixmD3Yk4V79JGfaCXxHJrLGg3i9D6ZuoCmm9u/+ED7tax 9zjyvLv9M8JUsLAg32df9UVaYroiVVytGbOIqT4PGQFYYQIO3aciaFkl53x3e8B3wo6X I7O6Ag47ycX+hkeNlB9HM79wv99BiOlfDI5jNaG4SM7T4fUWmp17TaC0sZUKwbtheQNb D3rArxLuNNNF0x3Se/y5AQTDKyG3oOz3qrOngqNU51TR66OKmOfnxFYkYXwqhYs/dWc9 HgtA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hZP3VRnS; 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=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g22si15535342edf.398.2019.10.23.13.29.04; Wed, 23 Oct 2019 13:29:29 -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=@redhat.com header.s=mimecast20190719 header.b=hZP3VRnS; 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=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2406354AbfJWOTm (ORCPT + 99 others); Wed, 23 Oct 2019 10:19:42 -0400 Received: from us-smtp-1.mimecast.com ([207.211.31.81]:28673 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2406348AbfJWOTm (ORCPT ); Wed, 23 Oct 2019 10:19:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571840381; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=b5XwPGWfRLOQx/XL/lGD6w9DJuiaWtEwmYD7upyMG5M=; b=hZP3VRnSAwhgxMPmNeIFTQpSt8hfelO5HCTtH5KRc8AXA5e9GVksB2SMgXiONKqcZFsIl+ 2eGzQKfHOGqSxjKtv7sf4mp9aGYCyC+h56XKfs+QY2kmSOxqZUJvOKY7cqw+VhhDdzcJPJ /avj4c3Y+3Na6fgzg+1gimkGrXRFuo8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-187-vDLmOuu8Pauaq5KU5RV9Dw-1; Wed, 23 Oct 2019 10:19:37 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4A85780183D; Wed, 23 Oct 2019 14:19:36 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-12-33.pek2.redhat.com [10.72.12.33]) by smtp.corp.redhat.com (Postfix) with ESMTP id 24C635C241; Wed, 23 Oct 2019 14:19:19 +0000 (UTC) From: Lianbo Jiang To: linux-kernel@vger.kernel.org Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, x86@kernel.org, bhe@redhat.com, dyoung@redhat.com, jgross@suse.com, dhowells@redhat.com, Thomas.Lendacky@amd.com, ebiederm@xmission.com, vgoyal@redhat.com, kexec@lists.infradead.org Subject: [PATCH 0/2 v5] x86/kdump: Fix 'kmem -s' reported an invalid freepointer when SME was active Date: Wed, 23 Oct 2019 22:19:10 +0800 Message-Id: <20191023141912.29110-1-lijiang@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-MC-Unique: vDLmOuu8Pauaq5KU5RV9Dw-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In purgatory(), the main things are as below: [1] verify sha256 hashes for various segments. Lets keep these codes, and do not touch the logic. [2] copy the first 640k content to a backup region. Lets safely remove it and clean all code related to backup region. This patch series will remove the backup region, because the current handling of copying the first 640k runs into problems when SME is active(https://bugzilla.kernel.org/show_bug.cgi?id=3D204793). The low 1MiB region will always be reserved when the crashkernel kernel command line option is specified. And this way makes it unnecessary to do anything with the low 1MiB region, because the memory allocated later won't fall into the low 1MiB area. This series includes two patches: [1] x86/kdump: always reserve the low 1MiB when the crashkernel option is specified The low 1MiB region will always be reserved when the crashkernel kernel command line option is specified, which ensures that the memory allocated later won't fall into the low 1MiB area. [2] x86/kdump: clean up all the code related to the backup region Remove the backup region and clean up. Changes since v1: [1] Add extra checking condition: when the crashkernel option is specified, reserve the low 640k area. Changes since v2: [1] Reserve the low 1MiB region when the crashkernel option is only specified.(Suggested by Eric) [2] Remove the unused crash_copy_backup_region() [3] Remove the backup region and clean up [4] Split them into three patches Changes since v3: [1] Improve the first patch's log [2] Improve the third patch based on Eric's suggestions Changes since v4: [1] Correct some typos, and also improve the first patch's log [2] Add a new function kexec_reserve_low_1MiB() in kernel/kexec_core.c and which is called by reserve_real_mode(). (Suggested by Boris)=20 Lianbo Jiang (2): x86/kdump: always reserve the low 1MiB when the crashkernel option is specified x86/kdump: clean up all the code related to the backup region arch/x86/include/asm/kexec.h | 10 ---- arch/x86/include/asm/purgatory.h | 10 ---- arch/x86/kernel/crash.c | 87 ++++-------------------------- arch/x86/kernel/machine_kexec_64.c | 47 ---------------- arch/x86/purgatory/purgatory.c | 19 ------- arch/x86/realmode/init.c | 2 + include/linux/kexec.h | 2 + kernel/kexec_core.c | 13 +++++ 8 files changed, 28 insertions(+), 162 deletions(-) --=20 2.17.1