Received: by 10.192.165.156 with SMTP id m28csp521619imm; Thu, 19 Apr 2018 03:09:43 -0700 (PDT) X-Google-Smtp-Source: AIpwx48cfqGemCg7eElvqIc1b7MJpCqtiKtKrAXxagjPN4UAy9c/iJDm0hExikHDySwj1A5Mgekp X-Received: by 10.99.171.72 with SMTP id k8mr4727604pgp.355.1524132583503; Thu, 19 Apr 2018 03:09:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524132583; cv=none; d=google.com; s=arc-20160816; b=myaqQNQJNemp5mu+Atp43WaNda28IJWpPIz5Mtv6fcaXJvB3WIeGPuw5Up9kTiR0B+ M+lkIhD4uZ5kA0BUlCbF6xhwKKl6N+veTj003dy0kpP1Hg1Q0tVm+Rl5P4CZJ5iy4vaP 4gNY/ehA+BQKDo/4Unxs7U9ts9wv2B8Xbr2CDxab5060n/NfsvpCUyF5vhU1bAnvrhir sF/c5yRTozY2HirbgxS78re4/fBUQjCA4p/534Z3Z1ytP1I12lmpltqJ8m76XOlzmUYK dx9BrP/C1zous/BubVZf3rP7Hk+kYGXyXjqcoJV2/1hJlAJuey4U01x0x23NhJtB5LYm 7+cA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=SlPrqXFdMKpJYMz54by/a+f89oHpl7N7/wvTQ6Vj20s=; b=sBgSw6C1jIqhbLyDqh6L5JW0ZrdXb2/E9x2mcZm84ET67alZyO/0wEToDvTBEEa+GX 2a4MCJp66mYiG0DPbZ/GsDCRIaRzJOEYSoC2OCJUzYYLJHesaHslU/E/cd9I7YuQK8HG AAXOHQ6gga0utFVwNuEyaudYogDmuwkqs8008IHS0yZ4evqcH8SWXHZ39XefRwSpQBFQ 9wPzcXgFVhkKidHCBR8U8gM4FyWggvSseBe4BjiroCjIIE3efCaYQek0t4zdfpt6c4Xy wJKJiH2INF72//A+47hDdr70J5var99uvnao6EhSZJO+3QfEjeCmvaSq3MnhPJXEi0v0 pvUA== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p2-v6si3168652plo.520.2018.04.19.03.09.29; Thu, 19 Apr 2018 03:09:43 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752496AbeDSKHw (ORCPT + 99 others); Thu, 19 Apr 2018 06:07:52 -0400 Received: from mx2.suse.de ([195.135.220.15]:38911 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751386AbeDSKHv (ORCPT ); Thu, 19 Apr 2018 06:07:51 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2A292AC43; Thu, 19 Apr 2018 10:07:50 +0000 (UTC) Date: Thu, 19 Apr 2018 12:07:45 +0200 From: Borislav Petkov To: Baoquan He Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org, robh+dt@kernel.org, dan.j.williams@intel.com, nicolas.pitre@linaro.org, josh@joshtriplett.org, Thomas Gleixner , Brijesh Singh , =?utf-8?B?SsOpcsO0bWU=?= Glisse , Tom Lendacky , Wei Yang Subject: Re: [PATCH v3 2/3] resource: add walk_system_ram_res_rev() Message-ID: <20180419100745.GC3896@pd.tnic> References: <20180419001848.3041-1-bhe@redhat.com> <20180419001848.3041-3-bhe@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180419001848.3041-3-bhe@redhat.com> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 19, 2018 at 08:18:47AM +0800, Baoquan He wrote: > This function, being a variant of walk_system_ram_res() introduced in > commit 8c86e70acead ("resource: provide new functions to walk through > resources"), walks through a list of all the resources of System RAM > in reversed order, i.e., from higher to lower. > > It will be used in kexec_file code. Of course, what is missing is the big *WHY* you need this to happen this way... > /* > + * This function, being a variant of walk_system_ram_res(), calls the @func > + * callback against all memory ranges of type System RAM which are marked as > + * IORESOURCE_SYSTEM_RAM and IORESOUCE_BUSY in reversed order, i.e., from > + * higher to lower. > + */ > +int walk_system_ram_res_rev(u64 start, u64 end, void *arg, > + int (*func)(struct resource *, void *)) > +{ > + unsigned long flags; > + struct resource *res; > + int ret = -1; > + > + flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; > + > + read_lock(&resource_lock); > + list_for_each_entry_reverse(res, &iomem_resource.child, sibling) { ... and the other thing that I'm not clear on is why are you slapping this function just like that instead of extending __walk_iomem_res_desc() to do reverse direction too? -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) --