Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp7121298ybp; Wed, 16 Oct 2019 04:13:08 -0700 (PDT) X-Google-Smtp-Source: APXvYqy/nmz9shxo3stqqrDaGxy5c06V+2spJCSYQIHNcV4fVYJlgmGim2sbICwaaoy74G3Xonel X-Received: by 2002:a17:906:6b99:: with SMTP id l25mr38455153ejr.233.1571224388104; Wed, 16 Oct 2019 04:13:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571224388; cv=none; d=google.com; s=arc-20160816; b=Wx9a6hx+s9Ah9htwoUsqI6KWo2fzmiR4psgAEr7MUomzTuoo4if79Tcen32ShVmPiq vCOyfaiD+E1QwSrGN1PIvRoMPuVXdEXi6E7olCqG+ie0NJf8D9AUcqCK6bh4R32xdMJR ZrBdifKMHRvvnKnXhxTros/Y5PuUUmkRztwV+Y1o+NoDNz4F1ddz3t6dY0k+zJFgBvWp NRAfabiiebfI31Zj0CSUvFPbeVACEJciY9j8KosnNPIwJ1N5LLPyPfxTbU8aA6wCnVG2 0g3h9M+cWUilGz61Aqjw8r+wFYxMliVSUcfhEWAtSGzOHWvCN76L2fzK99EG/m4XA9C0 ndow== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=cG4/TJ4SERvs9oKgGmAnxKkJvbhZkOFiGbN1Q8XI04g=; b=icW+p+w24P3XnjViy71boEx1aMWfY7CjbSicr06K67mMBgz5K8l4L3ui3ti/wYoow2 XHXyw4Hz/BEzUrY8yXgIDhSeKju4GLIWMX4EjjyrnhNLG9CRVE7o35zU6AHh17sLr5cY 5LZsFGGE6qtvBwOzdwl803kuWg42nRWC8OztxlIVoI3yIUAq093tFk+KPiGGgSR3+bpy p50H3g7K37pBBq8sBMVu2OAMMvryAW4Fe107Km/58Nzo4P5lktK7VS27w9xwx0mBGxbz oNZhhintHTEfXBZs6hlGUetfuYnAIveKWmToaNiSJv5+ew76dYsrvyd2aCpbDgBlsvF/ bT1Q== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (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 a3si15591924edr.20.2019.10.16.04.12.44; Wed, 16 Oct 2019 04:13:08 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390894AbfJPDYg (ORCPT + 99 others); Tue, 15 Oct 2019 23:24:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46848 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2390756AbfJPDYg (ORCPT ); Tue, 15 Oct 2019 23:24:36 -0400 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 mx1.redhat.com (Postfix) with ESMTPS id A13308980F1; Wed, 16 Oct 2019 03:24:35 +0000 (UTC) Received: from localhost.localdomain (ovpn-12-16.pek2.redhat.com [10.72.12.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 665675D6A5; Wed, 16 Oct 2019 03:24:21 +0000 (UTC) Subject: Re: [PATCH 3/3 v3] x86/kdump: clean up all the code related to the backup region To: "Eric W. Biederman" Cc: Dave Young , linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, x86@kernel.org, bhe@redhat.com, jgross@suse.com, dhowells@redhat.com, Thomas.Lendacky@amd.com, vgoyal@redhat.com, kexec@lists.infradead.org References: <20191012022140.19003-1-lijiang@redhat.com> <20191012022140.19003-4-lijiang@redhat.com> <87d0f22oi5.fsf@x220.int.ebiederm.org> <20191012121625.GA11587@dhcp-128-65.nay.redhat.com> <87tv8az2jq.fsf@x220.int.ebiederm.org> From: lijiang Message-ID: <54e8e316-1c7e-8d2e-270c-d5e178b46024@redhat.com> Date: Wed, 16 Oct 2019 11:24:16 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <87tv8az2jq.fsf@x220.int.ebiederm.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.67]); Wed, 16 Oct 2019 03:24:35 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2019年10月15日 19:11, Eric W. Biederman 写道: > lijiang writes: > >> 在 2019年10月12日 20:16, Dave Young 写道: >>> Hi Eric, >>> >>> On 10/12/19 at 06:26am, Eric W. Biederman wrote: >>>> Lianbo Jiang writes: >>>> >>>>> When the crashkernel kernel command line option is specified, the >>>>> low 1MiB memory will always be reserved, which makes that the memory >>>>> allocated later won't fall into the low 1MiB area, thereby, it's not >>>>> necessary to create a backup region and also no need to copy the first >>>>> 640k content to a backup region. >>>>> >>>>> Currently, the code related to the backup region can be safely removed, >>>>> so lets clean up. >>>>> >>>>> Signed-off-by: Lianbo Jiang >>>>> --- >>>> >>>>> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c >>>>> index eb651fbde92a..cc5774fc84c0 100644 >>>>> --- a/arch/x86/kernel/crash.c >>>>> +++ b/arch/x86/kernel/crash.c >>>>> @@ -173,8 +173,6 @@ void native_machine_crash_shutdown(struct pt_regs *regs) >>>>> >>>>> #ifdef CONFIG_KEXEC_FILE >>>>> >>>>> -static unsigned long crash_zero_bytes; >>>>> - >>>>> static int get_nr_ram_ranges_callback(struct resource *res, void *arg) >>>>> { >>>>> unsigned int *nr_ranges = arg; >>>>> @@ -234,9 +232,15 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg) >>>>> { >>>>> struct crash_mem *cmem = arg; >>>>> >>>>> - cmem->ranges[cmem->nr_ranges].start = res->start; >>>>> - cmem->ranges[cmem->nr_ranges].end = res->end; >>>>> - cmem->nr_ranges++; >>>>> + if (res->start >= SZ_1M) { >>>>> + cmem->ranges[cmem->nr_ranges].start = res->start; >>>>> + cmem->ranges[cmem->nr_ranges].end = res->end; >>>>> + cmem->nr_ranges++; >>>>> + } else if (res->end > SZ_1M) { >>>>> + cmem->ranges[cmem->nr_ranges].start = SZ_1M; >>>>> + cmem->ranges[cmem->nr_ranges].end = res->end; >>>>> + cmem->nr_ranges++; >>>>> + } >>>> >>>> What is going on with this chunk? I can guess but this needs a clear >>>> comment. >>> >>> Indeed it needs some code comment, this is based on some offline >>> discussion. cat /proc/vmcore will give a warning because ioremap is >>> mapping the system ram. >>> >>> We pass the first 1M to kdump kernel in e820 as system ram so that 2nd >>> kernel can use the low 1M memory because for example the trampoline >>> code. >>> >> Thank you, Eric and Dave. I will add the code comment as below if it would be OK. >> >> @@ -234,9 +232,20 @@ static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg) >> { >> struct crash_mem *cmem = arg; >> >> - cmem->ranges[cmem->nr_ranges].start = res->start; >> - cmem->ranges[cmem->nr_ranges].end = res->end; >> - cmem->nr_ranges++; >> + /* >> + * Currently, pass the low 1MiB range to kdump kernel in e820 >> + * as system ram so that kdump kernel can also use the low 1MiB >> + * memory due to the real mode trampoline code. >> + * And later, the low 1MiB range will be exclued from elf header, >> + * which will avoid remapping the 1MiB system ram when dumping >> + * vmcore. >> + */ >> + if (res->start >= SZ_1M) { >> + cmem->ranges[cmem->nr_ranges].start = res->start; >> + cmem->ranges[cmem->nr_ranges].end = res->end; >> + cmem->nr_ranges++; >> + } else if (res->end > SZ_1M) { >> + cmem->ranges[cmem->nr_ranges].start = SZ_1M; >> + cmem->ranges[cmem->nr_ranges].end = res->end; >> + cmem->nr_ranges++; >> + } >> >> return 0; >> } > > I just read through the appropriate section of crash.c and the way > things are structured doing this work in > prepare_elf64_ram_headers_callback is wrong. > > This can be done in a simpler manner in elf_header_exclude_ranges. > Something like: > Thank you, Eric. It seems that here is a more reasonable place, i will make a test about it and improve it in next post. Lianbo > /* The low 1MiB is always reserved */ > ret = crash_exclude_mem_range(cmem, 0, 1024*1024); > if (ret) > return ret; > > Eric >