From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD9DEC6778F for ; Mon, 9 Jul 2018 11:03:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8D0CC20882 for ; Mon, 9 Jul 2018 11:03:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8D0CC20882 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932688AbeGILDU (ORCPT ); Mon, 9 Jul 2018 07:03:20 -0400 Received: from foss.arm.com ([217.140.101.70]:56874 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932482AbeGILDT (ORCPT ); Mon, 9 Jul 2018 07:03:19 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5842A7A9; Mon, 9 Jul 2018 04:03:19 -0700 (PDT) Received: from [10.1.206.34] (melchizedek.cambridge.arm.com [10.1.206.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 62EDF3F318; Mon, 9 Jul 2018 04:03:16 -0700 (PDT) Subject: Re: [PATCH v10 03/14] powerpc, kexec_file: factor out memblock-based arch_kexec_walk_mem() To: AKASHI Takahiro References: <20180623022058.10935-1-takahiro.akashi@linaro.org> <20180623022058.10935-4-takahiro.akashi@linaro.org> <8a59db79-6379-550b-b20e-01036626904e@arm.com> <20180709054953.GR28220@linaro.org> Cc: catalin.marinas@arm.com, will.deacon@arm.com, dhowells@redhat.com, vgoyal@redhat.com, herbert@gondor.apana.org.au, davem@davemloft.net, dyoung@redhat.com, bhe@redhat.com, arnd@arndb.de, ard.biesheuvel@linaro.org, bhsharma@redhat.com, kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, "Eric W. Biederman" From: James Morse Message-ID: <68e7d558-91bf-a6f4-3e59-b93d5db0d77b@arm.com> Date: Mon, 9 Jul 2018 12:03:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180709054953.GR28220@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Akashi, On 09/07/18 06:49, AKASHI Takahiro wrote: > On Tue, Jul 03, 2018 at 05:36:24PM +0100, James Morse wrote: >> On 23/06/18 03:20, AKASHI Takahiro wrote: >>> Memblock list is another source for usable system memory layout. >>> A merged new arch_kexec_walk_mem() will walk through either io resource >>> list or memblock list depending on CONFIG_ARCH_DISCARD_MEMBLOCK so that >>> arm64, in addition to powerpc, will be able to utilize this generic >>> function for kexec_file. >> >>> diff --git a/arch/powerpc/kernel/machine_kexec_file_64.c b/arch/powerpc/kernel/machine_kexec_file_64.c >>> index 0bd23dc789a4..3d4be91786ce 100644 >>> --- a/arch/powerpc/kernel/machine_kexec_file_64.c >>> +++ b/arch/powerpc/kernel/machine_kexec_file_64.c >>> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c >>> index 63c7ce1c0c3e..563acd1c9a61 100644 >>> --- a/kernel/kexec_file.c >>> +++ b/kernel/kexec_file.c >>> @@ -16,6 +16,7 @@ >>> #include >>> #include >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -501,6 +502,53 @@ static int locate_mem_hole_callback(struct resource *res, void *arg) >>> return locate_mem_hole_bottom_up(start, end, kbuf); >>> } >>> >>> +#if defined(CONFIG_HAVE_MEMBLOCK) && !defined(CONFIG_ARCH_DISCARD_MEMBLOCK) >> >> The only caller is also guarded by these same ifdefs. Can't we remove this and >> rely on the compilers dead-code elimination to remove this function when its not >> needed? > > I don't think we can remove this #ifdef. > "for_each_free_mem_range[_reverse]()" is defined under CONFIG_HAVE_MEMBLOCK > in memblock.h. If some architecture wants to support KEXEC_FILE but > doesn't have HAVE_MEMBLOCK, compiling kexec_file.c will fail. Ah, I'd missed this, turns out memblock isn't ubiquitous! Thanks, James