Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp2189039ybx; Fri, 8 Nov 2019 01:05:02 -0800 (PST) X-Google-Smtp-Source: APXvYqwT9yHQ9kChXnwiAUxChj9wLJVSs1suS8a5CBKCj7VGVB2fEPZVhdDCsPz8pdwKI0pScVdn X-Received: by 2002:a05:6402:78b:: with SMTP id d11mr8802874edy.92.1573203902135; Fri, 08 Nov 2019 01:05:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573203902; cv=none; d=google.com; s=arc-20160816; b=xAHhwmR0ketq6vLatcEE2nPWKF7bwtWw/EWUi/2tTSn68sIHYykWsSRu6IpFSn8F73 NnRfza5yAPuarNhh38Y0w4Lozm2X3vLaIHQ7r8sDitnnvE1zi0gDOQ7PxL6u43kIlh2+ Hfzz801sj2AO9dRILyNjVXxAGWQ/ROUX/RaZdon+Zvl6PSz6+51Mhhs8ngY/QHHqwbGo aMkl2028jAXmI+RWA0f42zD+DbJMLz1nV93GBYcLVdvUN6/68/dEiXUgqhwsZSslvbOE uO3sqWzGPblOHKY6n0HsqPXT8fKE5W4DomeopclyUzpsS72945yf7mX7nGM8LOchVaOD 5f6Q== 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=R1cBLL262d5PbXD6F0/Q3yv5N9eCafn0HD776UEyAek=; b=uF03jS/8c5v+r2HflAP3cUVu4qHHPKxo1Rg08kR2lLRPovZgXudoGAxXCLy+LN9X+6 QCxq0+JtgB1f+t39+sVIPkz5WcAEGbZdsu3VbiNeQc4NHADBklwinUOVFyEAaBFoL5nQ MK/V5u4Yoy5nTf8OqN4WI9iv1hQWPCId8tdz/gG4vLQYf6TlRM/Fc1hwszu2qNpkMZMp cLPncM3aSkX43B6qMNWgrqPyGMtD8Nv8dOXgY0YpYE32+qvpmsr6lPKZixEXWCvyR4n7 gztvUlEmI6cV05cvaPvud4W7lGfGJX8wzu7w9XENQq26dWH4/lLoBt8sHr7oJ6A8Ck+S vjew== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SG91JlLC; 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 u25si2932193edr.22.2019.11.08.01.04.38; Fri, 08 Nov 2019 01:05:02 -0800 (PST) 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=SG91JlLC; 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 S1731148AbfKHJAv (ORCPT + 99 others); Fri, 8 Nov 2019 04:00:51 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:20214 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731127AbfKHJAu (ORCPT ); Fri, 8 Nov 2019 04:00:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573203649; 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=R1cBLL262d5PbXD6F0/Q3yv5N9eCafn0HD776UEyAek=; b=SG91JlLCeADjMyj5cTm5UO32Fa4MbJcFWFSa/rfsD+cHI1cxegWgd8kIQsoUxdN0Xnvt3X pchBTqqR1TWN9jf8vKlgQVKEIPwG/iia1OmsXz6e8Tn5KXpDXNCBXDTsXwgfbnjWOCx57W lEDWwjazV4sLIeptRolU/39IQ4GBp6o= 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-354-uiASuWksMTKVsC_UFMqNDA-1; Fri, 08 Nov 2019 04:00:45 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id ADB88477; Fri, 8 Nov 2019 09:00:43 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-12-112.pek2.redhat.com [10.72.12.112]) by smtp.corp.redhat.com (Postfix) with ESMTP id 94FFA5D6A5; Fri, 8 Nov 2019 09:00:32 +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, d.hatayama@fujitsu.com, horms@verge.net.au, kexec@lists.infradead.org Subject: [PATCH 0/3 v9] x86/kdump: Fix 'kmem -s' reported an invalid freepointer when SME was active Date: Fri, 8 Nov 2019 17:00:24 +0800 Message-Id: <20191108090027.11082-1-lijiang@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-MC-Unique: uiASuWksMTKVsC_UFMqNDA-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 1M 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 1M region, because the memory allocated later won't fall into the low 1M area. This series includes three patches: [1] x86/kdump: always reserve the low 1M when the crashkernel option is specified The low 1M 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 1M area. [2] x86/kdump: clean up all the code related to the backup region Remove the backup region and clean up. [3] kexec: Fix i386 build warnings that missed declaration of struct kimage 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 1M 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) Changes since v5: [1] Call the cmdline_find_option() instead of strstr() to check the crashkernel option. (Suggested by Hatayama) [2] Add a weak function kexec_reserve_low_1MiB() in kernel/kexec_core.c, and implement the kexec_reserve_low_1MiB() in arch/x86/kernel/ machine_kexec_64.c so that it does not cause the compile error on non-x86 kernel, and also ensures that it can work well on x86 kernel. Changes since v6: [1] Move the kexec_reserve_low_1MiB() to arch/x86/kernel/crash.c and also move its declaration function to arch/x86/include/asm/crash.h (Suggested by Dave Young) [2] Adjust the corresponding header files. Changes since v7: [1] Change the function name from kexec_reserve_low_1MiB() to crash_reserve_low_1M(). [2] Fix some warnings reported by kduild. Changes since v8: [1] Fix some build warnings reported by kbuild and make it as a separate patch. Lianbo Jiang (3): x86/kdump: always reserve the low 1M when the crashkernel option is specified x86/kdump: clean up all the code related to the backup region kexec: Fix i386 build warnings that missed declaration of struct kimage arch/x86/include/asm/crash.h | 8 +++ arch/x86/include/asm/kexec.h | 10 --- arch/x86/include/asm/purgatory.h | 10 --- arch/x86/kernel/crash.c | 102 ++++++++--------------------- arch/x86/kernel/machine_kexec_64.c | 47 ------------- arch/x86/purgatory/purgatory.c | 19 ------ arch/x86/realmode/init.c | 2 + 7 files changed, 36 insertions(+), 162 deletions(-) --=20 2.17.1